I'm relatively new to MSAL and have come upon a problem that is really frustrating me.
The program I'm making is a single-page app in the browser, and the problem that I'm having is that when you close the page and go back into it, all the login info is wiped.
That's most likely to it being stored in SessionStorage, so i tried doing this in the configuration to change it to LocalStorage (that of should stay):
cache: {
CacheLocation: 'localStorage'
},
It didn't change a thing. I tried editing some of the MSAL code to make it store in localStorage, and it did actually save it in localStorage, only for it to have the same problem. I've also tried making it save to the cookies using this:
cache: {
storeAuthStateInCookie:true
},
But it kept the good stuff in LocalStorage (that of didn't work) and put the information i needed into the cookies like so:
Although, when going out of it and back in, the cookies were wiped. Gone! What the hell is going on here, i just want my users to sign in and stay signed in.
Any ideas?
In your cache config, you should be setting 'cacheLocation' instead of 'CacheLocation'. MSAL configuration attributes are case sensitive, so you should have something like:
cache: {
cacheLocation: "localStorage"
}
However, if credentials are being cleared even from localStorage, you should try different browsers to make sure this isn't related to your browser being configured to clear it's storage when closing the window.
Related
We have been notified through a penetration test that our website is not securing the ASPXAUTH and ASP.NET_SessionId cookies.
I have made several changes to secure the cookies.
1) Added the requireSSL="true" attribute to the System.Web ->
Authentication -> Forms element in the web.config.
2) In the code that clears the ASP.NET_SessionId and ASPXAUTH cookies on initial login and logout that sets them to be secure and HTTP Only.
3) Added code to the Application_EndRequest method Global.asax that
specifically sets the ASP.NET_SessionId and ASPXAUTH cookies in
Response.Cookies to Secure and HttpOnly.
I can't figure out why the second one matters, but without it, the ASP.NET_SessionId cookie never shows up in the response object as secure.
Using the Chrome Developer tools I have taken a screenshot at several timepoints and some of the behavior looks unexpected to me. If someone could take a look at this and let me know if things are behaving correctly, I would very much appreciate it.
This screenshot was taken on initial page load after clearing cookies for the site:
Upon initial page load
The two SessionId cookies seem odd to me, why is there one that is secure, and one that isn't?
This screenshot was taken after clicking to log in to the site:After clicking log in
This one makes even less sense to me, why is the ASP.NET_SessionId cookie in the request not flagged as secure, or HttpOnly, is this expected behavior? I'm assuming no SessionId cookie being sent in the response is correct behavior
This screenshot was taken after clicking a link on the site to view a new page:enter image description here
If possible, this makes even less sense to me. The two cookies in question are sent in the request, both not set HttpOnly or Secure. Is this correct behavior? Additionally, is neither cookie appearing in the response correct?
I've spent quite a big of time here on StackOverflow and with The Google to try to find the correct way to configure these cookies. I just don't know if what I've done was correct, as I'm not sure what the fixed implementation should even look like.
Any help that can be provided would be very much appreciated.
Thank you,
-Nathan
Take a look at this similar thread on SO How to secure the ASP.NET_SessionId cookie?
Are you setting the secure flag of cookie during session start event? Something like this.
protected void Session_Start(Object sender, EventArgs e)
{
// secure the ASP.NET Session ID only if using SSL
// if you don't check for the issecureconnection, it will not work.
if (Request.IsSecureConnection == true)
Response.Cookies ["ASP.NET_SessionID"].Secure = true;
}
I'm learning token-based authentication in SPA and I got a question. Imagine that authentication process in my app is done the following way: whenever a user provides correct credentials I give him a token and change "authenticated" key in redux store to true, which allows a him to see private content in my app. The component I want to hide is coded like so:
if(this.props.authenticated) {
return <SuperSecretComponentOfIlluminatiMasonic666Chemtrails />
} else {
return <PublicComponent />
}
I wonder if it's a safe approach since anyone can install react-dev-tools, flip "authenticated" key in the browser and see the stuff I want to hide without providing credentials. Should my component be coded in a different way or everything is fine and I'm just getting something wrong? I've seen this approach in numerous amount of tutorials, but this question doesn't let me sleep at night
You should get the protected content from a server, and this server should only deliver the content when the user sends a valid token.
This way, yes, anyone can flip the switch in the client, but that only shows the UI components, without any data.
This is the usual approach when creating single-page applications. As long as you don't have secret or sensitive data right in your client from the beginning, they are as safe as your server / API that delivers the data.
I created a chrome app which uses the identity api, and it is deployed on the chrome web store. I cleared the dev version from my computer and downloaded it myself and it works wonderfully.
All it really does is get your identity, use that to grab a token that can be used to access the json representation of a google doc.
My teammate downloaded the app from the store and it and it isn't working at all. It seems that the app is not able to get a token, and therefore doesn't grab the json from the restricted google doc. I tried re-uploading the app with the key.pem in the root directory of the zip file, but with no luck.
What possible reason could there be for this? The only thing that I could think of is that my computer has a particular key on it. Any ideas.
Much appreciated.
The problem here was that I had previously cached my auth token from when I was developing locally.
Since your offline development version of the chrome app must have the same 64-character ID as the one that you upload (if you want api credentials to work for you), you have to be mindful of cached Oauth tokens. You can easily find them at chrome://identity-internals where you can revoke the tokens to simulate a user opening the app for the first time.
In my case, I initially had
chrome.identity.getAuthToken({
"interactive": true
}, function(token) {
inside window.onload. I later changed it to false, which didn't matter since I already had one cached for who knows how long. Thus, the app failed to authenticate for anyone else. Google recommends including a button or any other UI element for initiating the chrome.getAuthToken method because bandwidth issues often lead to a messy situation. I refactored this code to use interactive: true only if an auth token is not already present.
Sorry for being very stupid, but I really can't get my head around it. There are many different options like Cookies, LocalStorage, LocalForage, Session Cookies, etc.
What I need though is to store user information, and I have to do it on the server (I'm using node and express), I mean I can determine user on the server, and I have to send it to the client, and store it in browser's session store.
And I can't use just regular cookies, I don't want to persist that between the sessions.
with the cookie I could just do:
apt.get '/', (req, res)->
res.cookie 'user', currentUser
But doing similar thing with res.session doesn't work
Update after discussion.
Sounds like you should look at the basic approach of:
Take the user data you have on the server but want available in the browser, serialize it to JSON on the server
transfer that user JSON data to the browser in an HTML <script> tag whenever there's a full page load. Something like <script>window.USER = {"name": "Agzam"};</script>
when your JS on the page starts to run, you have access to it directly: window.USER
You can just leave it there in memory and it will go away when the window/tab is closed.
I recommend sharify as a secure and convenient way to do this. It integrates with express and browserify. If you don't use sharify, be aware that the rules for properly encoding JSON inside HTML are tricky.
I don't want to persist that between the sessions
Don't use localStorage or anything backed by localStorage then as they will persist longer.
I am building a webapp in Laravel 4.1, and I wish to force logout on browser / tab close.
A bit like your typical bank does... You log into your online banking, close the window, then go back to the site, you need to log back in again.
I have set the following in my app/config/sessions.php
'driver' => 'file',
'lifetime' => 0,
'expire_on_close' => true,
Safari and Firefox appear to work properly, however Chrome seems to keep the session cache as valid meaning that the user is logged in when they browse to my site.
Is there any way I can force Chrome to not keep the user logged into my site? Maybe there is something I can do in htaccess or similar?
As far as I can tell, Chrome does not have a specific issue when it comes to session cookies. I just tested my own app on Firefox, Safari and Chrome and the behaviour was the same for all three.
I would recommend opening up the Developer Tools in Chrome, clicking on the "Resources" menu and checking the cookies for your site. If things are working correctly, the cookie for your site should be listed with a value of "Session" in the "Expires / Max-Age" column. If not, then your app may not be setting the cookie correctly. Or you may have an old cookie hanging around, so just delete the cookie and try again.
BTW - Laravel 4.1 overrides PHP's native session handling and does everything itself, INCLUDING garbage collection. And it gets its session lifetime value from the 'lifetime' value above. So if you stick with your current settings, you are going to end up with ALL of your logged in users being logged out every time garbage collection runs (which, by default, will be 2 in 100 requests). You should change 'lifetime' to some value like 1440. I wrote a lengthy article on this problem just today in fact:
http://yetanotherprogrammingblog.com/content/laravel-40-41-session-configuration-problem-solved