The app I am maintaining has a custom Single Sign On implementation.
After receiving a valid token (which it provided earlier and stored to db),
the app executes a CustomAuthenticationFilter successfully.
The app works fine at "Jetty" on Eclipse. After a valid url request sent, the app successfully opens the welcome page which is just after login page.
Url request:
http://99.99.99.99:8090/MyApp/j_spring_security_check?tokenId=19d79b76-0d1e-4327-871b-0e8792e03be2
But when deploy it to a "tomcat", do a valid url request, instead of opening welcome page, it stucks at login page (below)
http://99.99.99.99:8090/MyApp/login.xhtml;jsessionid=3B8C865260E86F3609F75199A23A1120
The application deployed to both, ports purely the same. No exception in logs. Even I can read successful login logs in tomcat. I can't figure out why it behaves different?
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.
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 am starting to build an app that authenticates to a third party web service, and I'm having problems getting the authentication working. The login page is displayed correctly, but once the user logs in an error message is displayed: "The URL can't be shown".
I'm working on the iOS version of my app first, so I've only tested this on iOS so far using the Simulator. I initially thought that I wasn't registering the URL scheme for the redirect URL correctly, but if I put a breakpoint in AppDelegate.OpenURL(), and enter a URL with my URL scheme in Safari my app is launched.
Handling the OAuth2Authenticator.Error event didn't give any more information beyond the same error message.
This is my first time working with Xamarin Forms and Xamarin Auth, so I'm not sure what else to do in order to debug the problem. What else can I do in order to figure out the root cause of this error?
Turns out this was due to user error.
The redirect URL I was using didn't match the redirect URL I registered with the web service. Once I made them the same, the redirect URL worked as expected.
I've spent about a full day attempting to get a very basic Spring Boot app with Spring security up and running to no avail. I cannot find a single example of code that works when I run it.
This example is from spring.io. Here is what I'm seeing in that example:
I start at http://localhost:8080 and see the welcome screen.
I click a link to http://localhost:8080/hello, which redirects me to http://localhost:8080/login.
I enter "user" and "password" as specified in WebSecurityConfig.java, which redirects me back to the welcome screen. I was expecting to be redirected to http://localhost:8080/hello.
When I click the same link to http://localhost:8080/hello I get the login screen again.
I've tried debugging via #EnableWebSecurity(debug = true) but there are no errors.
The above experience is endemic of what I experience when I download every example. Admittedly I'm new to Spring, and presumably I'm making some kind of newbie configuration mistake. Any help would be greatly appreciated.
I downloaded the code and ran using maven and it works perfectly fine. After logging in, for all subsequent page loads of http://localhost:8080/hello loads the page and not the login page again unless of course I log out. The problem you have mentioned may be caused by ( with quite high probability since you have mentioned it's endemic) is that your browser may be having issue with transmitting the default JSESSIONID cookie (which is set on first page visit and updated ( as good security practise by Spring security) on first login. For subsequent visits same JSESSIONID is sent to the server and it is a key for the session object stored on server which contains the now authenticated/authorized user. If some how this cookie is not transmitted back to server ( one reason could be it's disabled in browser setting) then your application (protected by spring security) would not know that you are an already authenticated user and will show you the login page again. For e.g, for Chrome you can see the cookie settings at Settings --> Content Settings --> Cookies --> Allow sites to save and read cookie data (recommended). You can also view the cookie header getting passed on each page load post successful login by using Developer tool in respective browser.
I've tried to debug this without any success. I have a working Spring Application with GWT and Spring Security, but when I change the security-context around to use CAS authentication, I do get redirected to the cas page (usually), but after successful login, I get redirected to the correct url, but I get a "page not found error" at the browser level. After refreshing the page (same url), I'm logged in, and application loads as expected. No errors in the logs, as far as I can tell, no differences in what's happening in the application when using CAS vs normal spring security form login.
I believe this answered my question:
http://static.springsource.org/spring-security/site/faq/faq.html#faq-cached-secure-page
which basically states that if you're securing html pages, you're in charge of configuring caching, so that a cached page can't be accessed. In my case, this wasn't entirely clear, as the gwt services were still getting secured, so I wasn't seeing secured content, but still, that was the problem-