I've had some odd issues lately where after logging in to my application, rather than seeing the expected page, I get a json response rendered in the browser.
What's happening is I have a javascript routine on every page of the application that polls via ajax for new messages for the user.
There is a point when the user has signed out manually.. or is logged out when this ajax call is made and spring security is remembering this URL as the URL to redirect to again when logged in. So when the user signs in again, instead of being redirected to their dashboard, they are presented with the JSON response.
I need to prevent Spring Security from remembering Ajax called URLS, can anyone tell me if this can be done?
Related
I have a basic Spring (v5.3.23) web app running in an Apache Tomcat container (v9), and using eclipse as IDE. It uses Spring security for processing logins.
Everything runs almost correctly, but sometimes, after a successful login, the browser shows a white page, while there is no exception logged server-side or any other message. The problem appears both in development environment and production environment, so I don't think it's eclipse-related.
I have managed to pin down the problem to the following sequence :
Start tomcat container
Open login page in browser
After login, the secured home page is displayed correctly
Re-start tomcat (the problem occurs both when changes are made to the web app or not)
Refresh the browser, which redirects to login
Login again
The blank page is shown, no exception logged, no log messages in console
In this sequence, the problem occurs most of the time. If between steps 5 and 6 I refresh the page one more, meaning the login page is reloaded, the white page problem does not occur anymore, and the proper page is displayed.
A strong possibility is that it's something related to either the CSRF token in the login form or the JSESSION cookie of the container, but short of debugging through Spring code, I can't figure it out.
LATER EDIT
I narrowed down the issue to the CSRF token; if I change the value in the login form, I always get the blank page.
I have noticed the _csrf token has one value in the login form, then a different, but single value across all form that are used while the user is connected. Seems like the _csrf token is linked to the user session somehow.
The same happens when the login page is refreshed: different tokens in login & other app forms, but somehow,, sometimes, the initial token does not match what the server expects.
Currently, I’m developing a web app with server-side rendering using the Gin framework and I’m having a problem with login intercepting. When an HTTP GET request hits an endpoint, middleware is used to check the browser cookie and redirect the traffic to the login page. This works fine and after successful login, the user is always redirected to the dashboard page. My question is how I should redirect the user back to the originally requested URI instead of the dashboard page?
Also, a bit more complex scenario is on HTTP POST. It looks like the HTTP POST method doesn’t work quite well with a redirect. Also, how would I resume the request with the same post request after the user successfully login?
Thanks for the help!
For the HTTP GET scenario, this one is easy, you need to remember the original URL somewhere. The are a few ways you could go about this:
Store the URL in session information(if any is available, you do need sessions for non-authenticated users)
Store it in a query string, for example, redirect to example.com/login?original=https%3A%2F%2Fexample.com%2Fanother-page. Your login page can look for the query parameter and include it in the login form or make sure that the action of the login form matches the given URI. On a successful login attempt you can get the original URL form the query param and set it as the Location.
Store the original URL in a cookie, upon successful login you can just check the cookie value and use that.
As for the HTTP POST scenario. If you just want to redirect the same POST request to a different URL you can use a 307 Temporary redirect. A 307 will preserve the request body and method and not turn it into a GET request like a 303 See Other or 302 Found.
Resuming the original POST after showing the login screen and after a successful login is a little more complex. When you redirect to the login page you interrupt the flow of the user, maybe it is better to let the user re-post their request after logging in, instead of doing it for them.
Having said that, it is technically possible. We require two steps, first is storing all the data to recreate the request. Then after login completion we can render a form with this saved data and use javascript to submit the form. By adding:
<script>document.getElementById("myForm").submit();</script>
After your form, the browser will submit the form after loading the javascript, thus recreating the original POST.
The storage part can be done via the server side session or a cookie.
Let's say when you send a request to this url: ...?query=something&filter=another_thing, I am returning a web page with model attribute let's say model.addAttribute('result', resultList) then just for loop the result and print the values. (Template resolver could be jsp or thymeleaf, but there is no option to load resultList without model fashion - I mean there is no ajax request - )
What I want to do:
before loading the result (or loading the page), I just want to load google recaptcha.js first and
recaptcha will return a token,
then I will send token to the backend via ajax request.
After all if request is not bot, I will print the resultList
Is this requirement possible to implement inside the Spring boot application itself?
NOTE: I could not find anyway to do this. I just though that I could intercept the original get url then redirect to the another page, and this page will load recaptcha and send the token to my backend. If it is not bot then redirect to the original get url. However I do not know how to preserve original request
You're framing it slightly wrong, which may make all the difference.
When making a request, you want to make sure that request is authorized, before you handle
it.
That is where a recaptcha comes in.
To prevent unauthorized access, look into spring-security and recaptcha for that.
Once sufficient authentication has been achieved, your request will then enter your controller, and you can serve the page.
(of course, you could look into it doing it dynamically, but that will be a bit harder)
We have an issue with a asp.net core 3.1 MVC application. The application is using the built in asp.net Identity feature. The application is working well for existing users. If you hit any [Authorized] route, you are redirected to the login page as expected.
However, rather than have a registration process in our app, for new users, we onboard them via Stripe Checkout. Upon successful payment, stripe redirects to a specific route in our application /conversion/success/{sessionid} where sessionid is the Stripe session. This action is marked as [AllowAnonymous].
We then pull the necessary customer details from Stripe, create a user in our repository via UserManager<T>. We then call SignInManager<T>.SignInAsync() to sign in the new user, before redirecting the new user to the [Authorized] home page.
This process works perfectly when running locally on our test machines. Also, when running on our production server (Azure App Service) it also works perfectly when we hit the route manually through the browser.
However, when we actually run the process through Stripe, complete a payment and let Stripe redirect the customer, we get a strange behaviour.
The conversion route is hit, the user record is created, the sign in process completes but upon redirection to home page, the authentication middleware takes over, says it's not authenticated and redirects to the login page.
Just to compound matters further, if you then simply type in the home page route in the browser, the user is in fact logged in exactly as expected and the application works perfectly.
Using Fiddler to intercept the calls and look at headers, etc. we can't see why there would be a different behaviour when coming from Stripe as opposed to typing directly. We've even tried redirecting from a different website to our registration process and that works as expected too.
Any idea why we are seeing this behaviour?
---- Update ---
If, rather than redirect to home page at the end of the onboarding process, we simply show a simple View with an anchor link to home page, the user can then go to home page as expected.
Is it possible that you're rendering the page before authentication has been completed? Since UserManager uses a cookie to establish the user's session, authentication needs to complete before any response headers or body is set so that the Set-Cookie header can be sent in the response.
Based on what you described it sounds like the user is hitting the homepage after the redirect without having the authentication cookie. Where I'd start debugging this is by using your web inspector with "Preserve log" turned on and going through the Stripe Checkout process. Then, inspect the headers sent to the browser when you land on the redirect page & make sure the authentication cookie is set.
Between requests to Stripe and SignInAsync it seems possible that there might be a missing await, so the redirect is happening before the authentication context is updated. Hard to say more without seeing your code!
I'm using Spring MVC for a personal webpage with a local Tomcat 6 server. I'm using a default Tomcat configuration(what eclipse would setup by default).
In my controllers(using one controller for each page, and creating Session beans to pass information between them) I have two methods, one for capturing a POST and one for capturing a GET Request Method. The page logic will have the user click a submit button and will use a "redirect:abc.htm" return to send them to a new page or back to the GET method.
I'm not explicitly handling cookies, but do have all the information in Session Beans and am using Spring Security to handle security/user management.
I have a spring security configuration to redirect the user back to the login page if they are not authorized. I also have an ExceptionHandler catching HttpSessionRequiredException, though this is not what is triggering when I expire the user sessions(it's using the logic of my Spring Security configuration).
When the session is expired(I'm doing this through Tomcat manager) the user is redirected back to the login page. They are redirected after they try to do something(click a submit, or revisit any page except login.htm).
My issue is that once they get back to the initial page that their session expired at, if at the time of expiration they clicked a submit button, it is redirecting them past the initial page and handling the POST event from the submit.
Example:
User is logged in, and on the main page
User Session Expires
User, on the main page, click a submit button
User is redirected back to the login.htm page
User logs in and navigates back to the main page.
Instead of following the logic of the GET for the main page, they are treated to the POST of the main page, and I'm not sure where the POST variables are coming from.
Is there any way to trace where this error is coming from or what exactly is causing it?
This is done by spring-security. Spring security stores the request details in the session before redirecting the user to the login page. On successful login it will retrieve the request details from the session and redirect to that.
You can set the always-use-default-target attribute of the form-login configuration to override this behavior.