I have a node application and users need to login. We don't want to refresh the page after logging them in. The problem is we cannot add their sockets by their user id if not refreshed. I'm thinking if there are some alternatives for this, rather than refreshing the page.
I found out that socket id is saved in cookies. I just get it from the cookies after login then saved it to usersSocketList. This solved my problem.
I'm planning to switch an app from the old OAuth flow with the SFSafariViewController to the new flow with iOS 11's SFAuthenticationSession. Logging in isn't an issue, the transfer to the new API took me a few minutes to implement. However logging out has me baffled.
How?
I can't find any mentioning of wanting to offer the option of logging out anywhere in the docs. Using the old SFSafariViewController to invalidate the cookies? Nope, they're not shared anymore with SFAuthenticationSession. As soon as I restart the authentication session the user get's logged in automatically and there's no way out. So how to enable logging out? Or am I simply overlooking something completely obvious?
Update:
I found a "way that works" in a technical sense, but it's bonkers for the user: Open a new SFAuthenticationSession on the logout page that clears the cookie. But that means when logging out the alert view asks the user again whether he'd like to log in via the service. If yes is selected ("logging in"), the cookie clearing logout page is opened, the user has to manually dismiss the view, which can be caught by the completion handler and we know we can open the login view again.. displaying the login prompt to log out? I really don't like this solution.
Any ideas? Am I still overlooking a completely obvious solution?
Update 2: As no one has any clue about this issue so far, this is probably not an easy one. I have filed a suggestion with Apple via their report tool to either clarify how to handle this or build it into the API if not available. Will post if I get an answer.
Update 3: After pondering the issue a bit more we found another possible (although also unattractive) solution if you can influence the login page of the OAuth provider: make cookies very short lived. Then the login page can be opened without automatic log in. However this kills the whole purpose of sharing login sessions between apps.. and you need to be able to influence the login page.
Update 4: Since iOS 12 SFAuthenticationSession is deprecated and got replaced by ASWebAuthenticationSession. However ASWebAuthenticationSession does not change anything in regard to logging out. It's still not possible. Same issue as before.
With ASWebAuthenticationSession, setting .prefersEphemeralWebBrowserSession to true prior to calling .start() will force the user to enter credentials in the browser session. While not the same as logging out, this will allow a new user to login with different credentials when launching the next session.
Update November 2020: We used #react-native-community/cookies to clear cookies as a workaround. See the snipped below as an example.
import CookieManager from '#react-native-community/cookies';
CookieManager.clearAll().catch(e => alert("Error deleting cookies during logout"))
Previous answer from April 2020. This may be helpful for anybody struggling with this. I've spent few hours testing different options, going through apps and looking how they do it and reading forums/discussions.
I haven't find a way to programatically clear cookies and there is no documentation on Apple on this.
Using FB as an example. Logging out from Safari and deleting FB app doesn't help. Any app which is downloaded will not ask for login to FB if you logged in once before through ASWebAuthenticationSession or SFAuthenticationSession.
If users ask how to force login (even though it's not your problem as a developer) you can point them to: Settings -> Safari -> Advanced -> Website Data -> Remove All Website Data (or just the ones for the provider).
If your use case needs switching of users (like in my case where we use Azure AD and users share 1 phone) you have 2 options. A) Open ASWebAuthenticationSession with the logout endpoint (as mentioned, this is very weird UX). B) Open Safari as a separate app (not inside yours) and do login/logout there. Unfortunately, there is no way to redirect the user to your app after logout if the OAuth provider doesn't support redirect on logout.
It sucks because this prevents developers from creating nice experiences on iOS for use cases where a business needs to share device between multiple users and OAuth is used as identity provider.
One of the “best” solutions I have come across is to open a logout page in system Safari (not an SFSafariViewController). Because ASWebAuthenticationSession shares cookies reliably with Safari, the expired/deleted cookie then also affects the app.
See this GitHub page for more details.
It depends on which cookie stores your login info;
If it is a session cookie, then it is not shared with Safari as per https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession
So, simply clear your local session, and the cookies will be cleared on the next app launch.
If not, and the cookie persists, then like Martin said above, you should open Safari (not SFSafariViewController) with your logout URL, then redirect back to your app.
Please let me know if you need more info. I have tested extensively with all 3 ways of authentication (ASWebAuthenticationSession, Safari, and SFSafariViewController).
For iOS 13.0 need to add SceneDelegate.swift for UISceneConfiguration
Also need to update appdelegate for UIScene implementation
Add UISceneSession Lifecycle
It is working fine this way SFAuthenticationSession issue resolved.
In one of our apps, we've already started using ASWebAuthenticationSession.
Our use case for this goes beyond just retrieving access and refresh tokens upon login. What I mean by this is, the same session cookie is used when opening the web app (whilst logged-in to the iOS app) in order to save the user from re-authenticating themselves again and again. Eventually, time comes when the user finally decides to log out of their account and may thereafter attempt to re-login again using a different account. Since the user's session cookie may still be alive by then, any re-login attempt only flashes the authentication screen momentarily, logging them in automatically back to their first account without giving them a chance to enter the credentials of the second account.
To really force the user to enter their credentials every time we present the authentication screen, we have to add to our Auth0 query params the prompt=login pair.
Here's what the URL would look like:
https://example.auth0.com/authorize?
client_id=abcd1234
&redirect_uri= https://example.com/callback
&scope=openid profile
&response_type=id_token
&prompt=login
You can find more info about this on this Auth0 doc: https://auth0.com/docs/authenticate/login/max-age-reauthentication
I am using Spring Security 3.1 to handle login authentication, session timeouts and maximum sessions.
Also I am deleting cookies only on logout.
<logout delete-cookies="JSESSIONID" logout-success-url='logout page' />
Also I have set maximum sessions to 1 as of now for testing.
When I open my webpage in browser, it stores jsession id in cookie but the problem starts when I exit and reopen my browser. At this time I cannot find any cookies in the browser, they get deleted that is why I am not getting redirected to welcome page(page after login).
But when I login again, it shows an error message that I am printing:-number of sessions exceeded.
This possibly means that session remains alive on server side but it gets deleted from the cookie on client side due to which I neither see the welcome page nor am able to login on the login page.
What else I need to do so that cookies remain there in the browser till the session times out? I have set session timeout to 10 days
This is normal behaviour. JSESSIONID cookies are only valid for the lifetime of a browser session so are gone when you close your browser. This isn't something you can change.
There is no connection between the browser's perception of a session and the lifetime of a session on the server. Unless you actually log out, the server session is still there until it times out and is removed by the server (10 days in your case). Until that happens, trying to log in again will exceed the number of allowed sessions.
If you want to stay logged in for 10 days, you might want to look at using remember-me cookies rather than the standard servlet container session.
Unless you have a definite requirement for restricting the number of concurrent sessions a user can have, I would avoid using that as it will just cause you problems. You haven't actually shown your configuration for this, but there are really just two options. Either a user can log back in again and the previous session will be marked as expired, or attempting to log in a second time will cause an error until the previous session has timed out, or the user logs out to explicitly invalidate it. The behaviour is controlled by the error-if-maximum-exceeded namespace attribute.
just wanted to know:
In my rails 3 app when a user logs in, i store their id in a session variable like this
session[:id] = #user.id
i noticed that when i login and then close the browser the session is destroyed. Is this wise to do or better to create a logout feature to destroy the sessions. What can go wrong if i leave it as is.
Thanks for help
I noticed that when I login and then
close the browser the session is
destroyed. Is this wise to do.
If this is happening then it's good if session get expired/destroyed when user closes browser. This is what mostly done in websites.But can be hard when you are trying to providing remember me or always sign in like functionality. In this case you might not have to destroy session when browser is closed.
or create a logout feature to destroy
the sessions.
You can create a logout feature to destroy session but call this when user hits logout link.
I have a web application running on Spring Webflow with Spring Security. I have a problem logging out because my app kinda remembers the last page after logging out. When I press back or directly paste the URL to the address bar it can direct the page to the login page, but if I login it will go directly to the last page I went to before logging out. It tends to remember its last state. Below is my application-config snippet.
<security:logout logout-url="/logout.do" invalidate-session="true"
logout-success-url="/logoutSuccess.do" />
Link in my page
#{label.labellogout}
The expired-url attribute
The URL a user will be redirected to if they attempt to use a session which has been "expired" by the concurrent session controller because the user has exceeded the number of allowed sessions and has logged in again elsewhere. Should be set unless exception-if-maximum-exceeded is set. If no value is supplied, an expiry message will just be written directly back to the response.
Sounds like your session is still valid after an Logout. try to make it invalid after logout.
Text is from:
Spring Doc
Not sure that I correctly understand your problem but:
B.1.1.4. session-fixation-protection
Indicates whether an existing session should be invalidated when a user authenticates and a new session started. If set to "none" no change will be made. "newSession" will create a new empty session. "migrateSession" will create a new session and copy the session attributes to the new session. Defaults to "migrateSession".
If enabled this will add a SessionFixationProtectionFilter to the stack. The session fixation protection options on namespace-created instances of AbstractProcessingFilter will also be set appropriately.
Can be read here link