JSF sends an redirect to the webbrowser. But for some strange reason the browers doesn't react on the redirect.
I have been able to identify when this happend, but not why it happend.
The system is coded in Primefaces 4.0, Glassfish 3.1.2.2, JSF 2.1.11.
The receipt for creating the problem is:
1.) Have a session-timeout (for test purpose it is set to 2 minutes).
2.) Login to the module.
3.) Wait to the session timeout expire.
4.) Press the logout button.
5.) The logoutbutton will fire away an event to the login/logout module. Which will contact the IDP (SingleSignOn/SingleSignOut provider).
An response that the user is not valid will be recived. The login/logout module, will response back to the user with an Redirect URL.
The webbrowser will get the response. But do nothing.
It is possible to see this with the F12 button in the browser (Chrome).
If I take that response URL and paste it into another browser/tab. The browser will send the user to the right location. In this case,
to the IDP:s inlogging module.
Here is where it gets a little bit confusing for me.
If I open a clean new browser. With no session active. I take the URL to the "secure" page, and enter it to the URL-line. Press Enter, and
I can see that the browser will try to access the page. But then an authorizationFilter will fetch the request/response.
Identify the users as not logged in user. Then send the user (response.redirect) to the inlogging module.
Which is the right behaviour.
When it comes to the problem describe above. I can see in every log, and in the browser development window. That the same thing happend
when the session times out.
The only differences what I can see, is that the users browsers is not redirected to the loginmodule.
From a user perspective, it seems like the logout button is dead.
This is an problem with a twist. On that page, there is a button to download a file. If the user press that button. The file will be downloaded.
Once the file have been downloaded. There is no problem for the logout button to redirect the user to the right page.
So here is another question on the same topic. Why? It seems like the system "refresh" it self, and become active again.
Overview of the different modules:
Loginmodule: Redirect the user to the LoginModule, and get a answer back if the user is authorized for login or not. I.e. the IDP sends an SAML to the loginmodule.
IDP: An identity Provider.
GUI-module: The module that the user tries to access. Primefaces 4.0, JSF 2.1.11
The GUI module have an AuthorizationFilter, that checks so that the user is authorized and authenticated (got a valid not tampered SAML) to be on the GUI module.
I would be really happy for any hint suggestion that could lead to that I can solve this problem. Or even better, an clear instruction how to solve it.
Related
I have a web application (React js with Kotlin backend) that has normal email + pw (plus PIN) login, and it also supports 3rd party authentication (Google and Facebook). It works on mobile and web, however, when I open my webpage through Facebook app - which opens it's own browser - and try to log in with 3rd party authentication, I can click on that "Continue as me" button, but then the page refreshes and I'm not logged in. I saw the same thing happen on other sites too, e.g. Figma, Pinterest, etc. I thought it's impossible to log in this way anymore, however, I just noticed that you can actually log in to Stackoverflow this way (so facebook app -> facebook browser -> stack overflow -> 3rd party auth and it works).
Has anyone figured it out how it was possible for Stackoverflow to do this?
Ok, I found the solution. The problem was that when a user clicked on 'Login with FB' button on my site, I sent a request to fb to get back a content of a login window and I created a pop up window where I rendered it, I put on a listener on that pop up window and once it was done, then I got the access token and sent it to backend and logged the user in. On a normal browser it works perfect (both pc and mobile) but as I mentioned above it didn't work in an in app browser like facebook app.
The issue was that facebook app opens a website in it's own browser that doesn't handle any pop ups, so after a successful authentication I saw that nothing happened and it was because we were not redirected to the original window where we should have, and it had the token in the url. So the solution was instead of making this pop up window for FB login, just redirect the user to the fb login page (and stay on the same window), and once the login is successful, just handle the token as is.
I created a static Web site using Azure Static Web Apps (under the Free plan for now -- not sure if that's relevant to the issue at hand.) I can access the Web site through an ***.azurestaticapps.net URL.
I then tried to test Azure Active Directory authentication per Microsoft's instruction from this page:
https://learn.microsoft.com/en-us/azure/static-web-apps/authentication-authorization
My problem is that logging out does not seems to work as I would expect on a normal Web site. I could log out, but when I tried to login again (hoping to use a different Azure AD account,) the Microsoft login screen flashes by and I got logged right back in with the user that I just logged out from. Switching to a different tab doesn't help.
Steps to repro:
Navigate to /.auth/login/aad and login using a Microsoft Account. Say NO to 'Stay signed in?' prompt.
Navigate to /.auth/me to see the basic information on the logged in account to prove that I'm in the logged in state.
Navigate to /.auth/logout to logout. Immediately, navigate to /.auth/me again to confirm that my static Web App regards me as 'logged out.' I'd see this:
{"clientPrincipal": null}
Navigate to /.auth/login/aad again. Microsoft login page flashes by, and I am logged right back in with the previously logged out user.
Things that sort of worked
Any of the two actions below alone seems to make the browser forget my logged-in state:
Close the whole browser and relaunch it. I'd get asked to pick the previous user (and then enter the password) or choose a new user. This sort of works but reminds me of some Web sites 15-20 years ago that said 'For security reasons, please don't forget to close your entire browser after logging out from this one tab.'
Open a new tab in the same browser, and navigate to hotmail.com. That tab will enjoy my logged-in state from the Static Web Apps tab. I'd see my mails right away. Then I log out from the hotmail.com tab, switch back to ***.azurestaticapps.net tab and see that I am still logged into my Static Web App. Good! Then if I log out from my Static Web App and try to log back in, it has forgotten my logged-in state this time. In other words, logging out from the hotmail.com tab is somehow more powerful.
I also tested /.auth/login/google too and the same problem arises! So the issue seems to be on the Azure Static Web Apps side, not how idPs handle their logout process.
Am I missing anything obvious?
I'm working on a windows based application in C++ that requires facebook login. I'm using using Ole Embedding/ActiveX control with the CLSID_WebBrowser component (IWebBrowser2) to do the authentication.
This works pretty well in so far as I create a window, embed the activeX web browser control, and then I direct it to the facebook login with an 'authorization url', such as...
https://graph.facebook.com/oauth/authorize?client_id=xxxx&redirect_uri=https://www.facebook.com/connect/login_success.html&scope=basic_info
xxx is set to our app id.
This works, and you can login. The problem is if I quit and restart the app, even if I've selected 'keep me logged in' in the web page, I will generally have to retype in my password.
I say generally, because if I don't use the facebook auth url above, and say go to www.facebook.com, within my active x control and log in - it will remember that I'm logged in, and I don't have to type in password if I shutdown and restart the app.
As another side detail all of this is separate from the behavior of just running IE. If I run IE and login - it has no effect on the login inside of the app. And it's not something that is unique to my implementation of ActiveX control embedding. If I run the JUCE library demo - which has a web browser active X component, it has the same behavior as with mine. That is...
1) I can login via https://graph.facebook.com/oauth/authorize - but if I restart the demo, it won't remember my previous login
2) If I login via www.facebook.com then it does remember I've logged in
+ Actually a login like this in JUCE will allow me to login without a password from my app
3) Login from IE has no effect
It's tedious to have to login every time, and seems like incorrect behavior to have to do it if you select 'remain logged in'. It does not appear that it's a problem with the ActiveX control saving session state - as session state is maintained when I use the www.facebook.com login. It may be worth saying - I can't use www.facebook.com login, because it doesn't return the information that the app requires to work, that's what the authorize style url is all about.
The implication seems to be that facebook is doing something different in these scenarios - it's not storing the login information if you use the authorization url.
So my question is how to fix the problem - such that 'remain logged in' will remain logged for an application authentication through the authorization url?
I guess as a work around, you could store the authorization token in the app, and try and see it that token is valid at startup perhaps. I'm not sure that's the 'right' way to do it.
Also note - my original implementation used Ole Automation (effectively my app controlled a separate IE process), and it had none of these problems. BUT unfortunately with IE 11, Ole Automation seems to have been broken.
Thank you for your time and wisdom.
I didn't find away to honor 'keep me logged in' within facebook. Instead, if a user logs in I store the authorization token encrypted in a file. If they restart the application, it will attempt to login using the stored auth token. If it fails, a standard login sequence is pursed. This is equivalent to acting as if 'keep me logged in' is always set, which isn't right, but is better from a usability point of view than the opposite.
It may potentially be possible to lookup the 'keep me logged in' element from the DOM of the webpage, and see what it is set to. This seems kinda fragile.
I remain open to suggestions on, how to 'do this properly'.
Please forgive me if this is a silly question. We're running into a problem attempting to authenticate. The issue seems like a straight forward one so I'm sure it's something silly we're over looking.
Step 1: User hits our tab app front page. This page is public and doesn't not require us knowing who the current user is.
Step 2: There is a button on this page that let's people join our application. This takes the user to another action on our controller and here is where app authentication is checked. If the user has not authorized the application, we are providing the re-direct URL to our app being hosted on our server (I believe this is the crux of our problem).
Step 3: The user authenticates the app, however, when being re-directed we're taken outside of Facebook to the target page.
Do we have to re-direct back to our page tab and if so how can we exchange the code for an access token?
Thanks in advance,
Eric
Set a "Namespace" for the app. That creates a new link to you app which ends with the namespace. Use this new url as return_url when calling for authentification.
I have a query related to Login in ASP .NET website.
When a user logs into system, his interface opens. But, when I click back from menu, it goes to Login page again. That is fine. But, when I click Forward from menu it opens User's interface back. This should not happen, it should ask to login again. I wrote Session.Remove(), but still it is not working..
Assuming you're using FormsAuthentication...
To sign a user out, you don't abandon the session, you use FormsAuthentication.SignOut()
To get the desired behavior, put this in the Page_Load event of your login page.
Also, you'll want to ensure that your login page is not cached, otherwise this may not run when the user clicks the "Back" button.
http://msdn.microsoft.com/en-us/library/system.web.httpresponse.cache.aspx
When you say back from menu you don't mean the "back" button on the browser do you?
If not try:-
Session.Abandon();
Also are you setting any authentication tickets? If so you will need to clear these as well.