I've recently started developing e-commerce app with multiple types of users, and currently I am experiencing some issues with browsers Page Cache. Here is one example for user authentication
Authentication Token is generated
Authentication Token is written into the database
Authentication Token and its expiry is saved into the user session
I wrote middleware that checks if user is authenticated and if its authorized (checks the token and access level) as well as expiry - tested it, it works. On "Log Out" I am destroying a session and renewing the token with Session.Destroy(r.Context()) and Session.RenewToken(r.Context())
Here is the problem:
I log in as "Admin" and go to DASHBOARD page for which only admin users are authorized to access.
I logout
I login as regular user and click "BACK' on browser it takes me to Dashboard page when it should not. But, when I refresh the page it does say "UNAUTHORIZED" which is what I was expecting when clicking "back" or something.
I was searching through the internet and found a "solution" where I set the headers in the following manner:
w.Header().Set("Cache-Control", "no-cache, private, max-age=0")
w.Header().Set("Expires", time.Unix(0, 0).Format(http.TimeFormat))
w.Header().Set("Pragma", "no-cache")
w.Header().Set("X-Accel-Expires", "0")
This however, does not work for me. I do see these headers in the NETWORK card when I open my Web Developer Tools, but problem remains.
What am I doing wrong?
Related
I've developed a single sign on strategy with login/logout/refresh on multiple domains with JWT Tokens. The SSO is managed via postMessage iframes as described here: Single sign-on flow using JWT for cross domain authentication
The problem I have is when the user has Third Party Cookies disabled in his browser.
Then there the postMessage technique with iframes do not work anymore:
When passing a message top-down (setting the cookie inside the iframe), it fails
When passing a message bottom-up (reading the cookie inside the iframe), it also fails
I therefore have to develop a fallback workflow for all users with disabled Third Party Cookies.
It works the following way:
User logs in an the auth server
A cookie isset at the auth server
User gets redirected back to pageA and another cookie (with the same content) isset there
User visits pageB and wants to login there
User gets redirected to the auth server. The cookie is recognized and user gets redirected back to pageB and another cookie (with again the same content) isset
All 3 cookies are now "in sync"
The problem now arises, when user refreshes his token on pageB. then he cannot refresh it again on pageA and he has to login again on page A
Because the TTL of the access token is very short, this is a very bad experience
My conclusion to this: If a user has disabled Third Party Cookies, drop the whole SSO. The user simply has to login on every page.
Am I right or is there something I am missing?
I'm developing a Sina Weibo integration and I'm doing the oauth correctly but I have a problem with authorization page. When I click on enter, I accept authorization page and I can loggin correctly but if I log off and I try to clic another time enter, I can only see a login page, but no an authorization page.
How can I force that an authorization page shows always?
The correct login flow consists of the following:
1. redirect user to the authorize page with the app's client id
2. client logs in to weibo (authentication)
3. client grants the application requested permissions (authorization)
4. client is redirected to your app page.
I believe the step you are asking about is #3. Once a user has granted your application permissions, this will be stored on their weibo account. The user will no longer be prompted to grant permissions every time the user logs in. The exception is when the user has removed your application from their weibo account. Thus there is no way for your application to force the user to reauthorize your app every time. It is unclear under what circumstances this would ever be required/beneficial.
As a side note:
If a user is already logged in, #2 is skipped by default. The user can be forced to relogin with the forcelogin parameter described in the docs: http://open.weibo.com/wiki/2/oauth2/authorize/en
I've got some things in my mind, I thought I'd ask the veterans here. I'm creating a website using Razor syntax and WebMatrix. I'm currently implementing a user login system into it. So my questions are:
In WebSecurity, when a token is generated (for creating new account, or recovering password, etc.), is this token a public key? Can it be safely emailed to the user over unsecured network or email. Is it a good practice (or useful) to further encrypt this token?
I've set my secured pages to not to cache on web browser, i.e. pages which are accessed by user after he signs-in with his password. I think its a necessary action because when a user logs out, I don't want the user to press the browser's back button and see the secured pages again. So I set all the secured pages' expiry as follows:
Response.Expires = -1;
Response.Cache.SetNoServerCaching();
Response.Cache.SetAllowResponseInBrowserHistory(false);
Response.CacheControl = "no-cache";
Response.Cache.SetNoStore();
My question on above is that if I set my pages to expire immediately, the browser does not cache anything and reloads the page every time user visits it, does it mean that the browser will not even cache the linked style sheets, script files and images? I've set my images to preload so that the website's presentation works smoothly; will the immediate-expiring of webpage cause these images and everything to be loaded all over and over again on each page?
Thanks.
It's not a "public token", in the sense that anyone who gets access to that token can use it to reset the user's password and log in. So it does need to be sent securely, and the reset link should require SSL.
No, the setting of cache expiry on specific pages will not affect the caching of other content. You can set the cache policy/headers of static content using IIS manager, or in the web.config.
I am configuring Azure ACS with "Google" configured as IdP in my application. My requirement is that I do not want the IdP login page to be displayed every time I try to log into my application. I have set my ACS token lifetime to the maximum period so that my token is valid for a day.
First time when I log into my application and I select "Stay Signed In" in Google login page, I am able to log into my application. I now close the browser, reopened the application, I am successfully rediercted to the application home page without any credential request. (as ACS internally uses the session token created intenally which will be used in next requests)
But if I do not select "Stay Signed In" in IdP login page, and proceed the same steps, I am asked for credentials. Any idea why is this happening? Is there a way I can manipulate the session token and validate the ACS token which was earlier issued to me ?
When you select "stay signed in" at Google, it writes a persistent cookie, meaning that you'll stay logged in even if you close your browser. By default, your application's cookie is scoped to the session (assuming you're using WIF). When you close and reopen your browser, the original token and cookie are gone. Your browser redirects to ACS, which redirects to Google, which redirects you back again because of the persistent Google cookie. Running your session using Fiddler or HttpWatch should show that, even when you choose "stay signed in", you're still being sent back to ACS and Google and getting a new token.
It sounds like what you want is your RP to "remember" the user so they don't have to log in again within the token lifetime. To do this, your federated cookie (the one with the token in it) needs to be set as persistent, rather than session. If you're using WIF, this can be done using CookieHandler configuration on the FederationAuthenticationModule (see PersistentSessionLifetime).
I know I can't logout an HTTP authentication.
Overwriting through the Location: http://logout:byebye#yourserver.example.com/ way seems to work on most browsers, except IE.
I was wondering however if I could let the users overwrite the Authentication data.
So say the user has some auth data in its browser, now they go to my /logout page, and it sends back the 401 headers so that the authentication window pops up and they can overwrite it.
However, when they click OK (auth data is now overwritten in the browser) the /logout page reloads, and there's no way for me to validate the new data because the page will reload after I clicked OK and it will run the Auth headers again and it will show the popup again.
So basically, how do I validate HTTP auth data if there's already some data set in the browser?
when they click OK (auth data is now overwritten in the browser) the /logout page reloads, and there's no way for me to validate the new data
You just have to reverse-validate the submitted data: if the user supplies proper auth, return the 401 response; if the user supplies bad auth or no auth, return a 200 or 302 to signal that the new bad/no auth has been accepted. The browser will then continue to use the bad/no auth for future requests.
Add directions something like “Click here and then enter no username or password and click OK” and you've got yourself a workable, if slightly shonky logout feature for HTTP Basic Auth.
(This is easy assuming you're spitting out the auth headers yourself from a script; it's not generally possible to pull off if you're using your web server's Authentication handling features.)