I'm having a weird problem with my angular app. When the user is logged in and hits "refresh" in the browser, the app loads the log-in template which is part of the main index.html file. It does not, however, kill the user session, but the user can't get any where else in the app without re-authenticating. Can anyone offer advice?
When a user refreshes the browser, your entire angular application disappears and gets restarted. That's how SPAs ("Single Page Apps") work.
If you want to have the user not log in every time they do this, you have to save enough information in the browser itself to know that he or she has already logged in. You can do this by storing some information either in a cookie or HTML5 local storage, and checking to see if the login information is stored before you call your authentication service.
Also, if you use standard http BASIC authentication the browser itself will cache the authentication credentials.
Related
Say I have two applications open, one in each tab, and they both leverage the same SSO server. The user globally logs out (front-channel) in App A, but App B remains open in another tab. The front-channel takes care of wiping the cookies but ideally there would be a way to redirect App B to a "you've been logged out" page. However, since it's not possible to detect HTTPOnly cookies via javascript, how can the javascript running in App B's tab detect the removal of the cookie and direct the user? I suppose we could write a non-HTTPOnly cookie as well and monitor that but I thought there may be a better solution out there.
IdentityServer4 supports this via the "session status change" spec here:
https://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification
This allows your app to ping (via postMessage calls to an iframe) for changes to the current session and receive a response indicating if it's changed or not. This all happens client-side and it uses a non-HTTP-only cookie which is populated with the current session ID.
The endpoint in question is advertised as check_session_iframe in the /.well-known/openid-configuration
oidc-client-js implements this out of the box but for a server-side app you may have to roll your own.
I have an application that uses express.js as the server side language and React on the front-end. I use passport.js to authenticate routes in the server, using local login and facebook strategies (no JWT). I use express-session to manage the session, which seems straight forward ( or insufficient, which I do not know yet, for my case, as its work in progress ).
My requirement is to hide/show few links in the Header component.
i.e.,
Log In
Sign Up
should show up in index page, when user has not logged in, but hidden when he is logged in. Likewise, few links should be hidden when the user is not yet logged in.
What is the best wat to check this from the client? Making an AJAX call is not ideal, as I may have more use cases of checking if the user session is valid from the client.
I can see the default connect.sid cookie, which the express creates, but how do I make use of it, or is there a best way for the client to know that the user is already logged in.
You have a couple options. Here are some:
You can check for the presence of a different cookie in the browser, and use that as your metric for whether or not you are "logged in". Your browser won't know if the session has expired server side, so you still have to account for the fact that you may be logged out and not know it. Additionally, you have to be sure to clear this cookie when logging out and set it when logging in.
When starting, your browser can make a AJAX request to get the currently logged in user. This might be useful for all sorts of things, such as displaying the user's name when logged in. You really only need to do this once (on page load and on login), then keep track of the user's login state stored in memory. You mentioned you don't want to do this, but it is fairly common.
When loading the page, you can inject the user into the page. For example, when the page loads there will be a <script> tag containing window.currentUser = null or an object representing the user. You can use this to "bootstrap" the login state without needing an AJAX request.
To clarify, you can't use the connect.sid cookie by itself because this cookie is just the ID of the session, not the session data itself. Only the server knows the session data that's being stored for that user, not the client. You need some way aside from this cookie for the server to tell the client that it's logged in, and the client to keep track of that state.
If you want the client to know from the ID component itself, you'll want to look at token options like JWTs.
i have an angularjs app, i am using cookie based authentication in this app. when i login with two different users in same browser window in different tabs my cookie gets override. For example i am logged in with a user 'A' in first tab of browser and i am logged in with a user 'B' in second tab of the same browser window. when i check the cookie in browser, i only see the information about last logged in user. and when i try to navigate through application with user 'A' i get wrong data.
my question is is there any way i can skip login screen if a user is already logged in my application? so that no other user can login within same browser?
i tried to use resolve:in AngularApp.config and tried to redirect already logged in user to /home but still i am unable to achieve it. any thoughts?
Once the login is completed you can save the status of the application in session storage. Then when you are initialising the application you can check the value exits in session storage or not and redirect user to different page depend on the value. Make sure you are removing the stored value in session storage when user logout from the application
I have a mobile website written in angularjs, with my backend in Spring Boot. Right now, I have my own login page and can login a user without any trouble. However, if the user ever clicks "back", "refresh", etc., the client loses the user's id and login info (obtained from server on login). I need to make sure that this info is maintained and clicking "back" or "refresh" doesn't break everything.
Secondly, a user that knows the url's after login can type those url's in the browser and access them without logging in. I can stop them accessing anything on the server, but not sure what I can do on the client to redirect them to a login page in this case.
Any help would be greatly appreciated!
You should keep in mind that everything running in browser is stateless, there's no way to keep trace of the previous state.
Right now, if the user performs a refresh (or another similar action), Angular loses everything (AuthData included).
You have many way to work around that limit:
Perform an http request after the application bootstrap (have a look at the angular.module().run method
Save a cookie and use the server to print initial data layer directly on the dom via json
Save on local/session storage
Personally, I prefer cookies because that lets the server to work decoupled from the client.
In reference to your comment..."if the user ever clicks "back", "refresh", etc., the client loses the user's id and login info (obtained from server on login)."
Is there any reason you need to maintain the user id or login info after a successful authentication?
If Spring Security is setup for basic authentication, after a successful login, a Session Cookie will be sent back on the response to the client. On all subsequent requests to the server, the same Session Cookie will be sent on the request and the previously authenticated session will be re-established. You just need to ensure that your Angular client is passing cookies when issuing requests.
Take a look at this sample on how this is done.
My context:
An AngularJS application using the Javascript Facebook SDK, and my distinct server (REST APIs).
Workflow:
User is logged in the client through the FB SDK using the method FB.login(callback).
This later gives a short-lived token that is then sent to the server in order to transform it to a long-lived token.
I'm interested in the mechanism of refreshing the long-lived token after 60 days.
So, reading the doc, we found this:
Even the long-lived access token will eventually expire. At any point,
you can generate a new long-lived token by sending the person back to
the login flow used by your web app - note that the person will not
actually need to login again, they have already authorized your app,
so they will immediately redirect back to your app from the login flow
with a refreshed token - how this appears to the person will vary
based on the type of login flow that you are using, for example if you
are using the JavaScript SDK, this will take place in the background,
if you are using a server-side flow, the browser will quickly redirect
to the Login Dialog and then automatically and immediately back to
your app again.
If I interpret it well, when user is ALREADY logged in through FB.login(callback), a simple redirect to the Angular Application's login flow would allow to get a new short-lived token.
I imagine that the FB.login is immediately run anew in this case, without user interaction, as written.
I want to test it simply, so what I've done is:
Logged in into the application through FB.login(callback).
Clicked on a dummy link making a simple redirect with: window.location.replace('/');
My application being a single page application, every URL should be considered as the authentication page.
But the FB.login isn't run in the background, as I expected from the doc.
What would be the reason?
Does it work only when the domain making the redirect is distinct from the client? (I just can't test this case right now)
Did I misinterpret the doc?