I have a basic site I made for practice purposes and have built a login/member type functionality with it. The weird thing is that when I try to login on different computers, some will login in properly while others will just redirect me and not log me in although my credentials are good. I am thinking maybe it is different security settings in the browsers for storing sessions, cookies? But all the browsers I tested on have cookies enabled but the site and login feature will only work for some. Any suggestions?
I had the same problem once and it was caused by the browser. If you redirect the user after login with
redirect(url);
try to replace that with
redirect(url, 'refresh');
IE doesn't play well with cookies and header redirects.
Related
I have a Webapp (HTML, JS, PHP) on an Amazon cloud server which is integrated in our companies network. Lets say the servers name is
dev-myapp.cloud.myentity.mycompany.com
This app is using the companies global SSO login by getting an oauth token from the SSO login page and then sending client, secret and callback (as usual). If Login is successful, the SSO login redirects to my callback (which in that case is my apps url above)
The SSO login creates many cookies in the browser. Most of them are flagged as secure but also some are not. For all of this cookies I now get an error
Cookie "xxx" will be soon treated as cross-site cookie against "path_to_any_of_my_sources" because the scheme does not match
I get this error for every script which is loaded (HTML, js, PHP, css) with FireFox.
The domain of the created cookies is
mycompany.com
so there should be no cross site at all.
What can I do to remove this hundreds of warnings, which makes debugging really annoying
If you need more information please let me know. Please understand I cannot provide you with real data from my company.
I was able to fix this same problem by clearing my cookies in the browser.
I've a group of employees whom use Outlook Web Access exclusively, and they are complaining that mailto: links on our intranet don't work for them because they don't open OWA (I can't change the settings on the individual machines, fyi).
I'm looking for some kind of way to have an intermediary page that I'll redirect them too when they click a mailto: link, which checks for an OWA login, and if it's found, will redirect the user to OWA. If no login is found, it will open a standard mailto: command.
MY PROBLEM: I can't seem to find a way to detect if they are logged into OWA. I can't use normal AJAX or Iframes because those elements are not allowed to inspect the contents of a page loaded from a different domain (our intranet is NOT on the same domain as OWA).
I even tried hitting the OWA url in code (C#) using the WebRequest class of System.Net, but I get a 400 error there for some reason.
I tried AJAX, IFrames and WebRequest against both the base URL of the OWA system, as well as the URL that you are redirected to for a login. All fail as described above.
Does anyone have a way of detecting an OWA login? I don't need to 'scrape' anything from a page in OWA, I just need a yes/no answer for if they are logged in or not.
Can you make a jsonp ajax request and just look at the 302 redirect url?
If you get redirected to owa/auth/logon.aspx, you are not logged in.
Using jsonp will let you work around cross domain security limitations.
Using Forms Authentication in ASP.Net MVC 3, it appears that the login cookie is cross-browser. When a user logs in in IE and then opens the site in Chrome, for example, they are already logged in. When they logout in Chrome and then refresh the page in IE, they have been logged out there as well.
Is this correct or am I moy loco?
How does this work? I didn't think browsers used a common cache for cookies.
They don't share cookies. Something else is going on. The logout can be explained in the way the server handles logouts though. If your server has a single cookie that is then invalidated all logins across all sessions will be invalidated making them all log in again.
I have read on some blog (sorry for not mentioning the reference but I can't find it anymore) that you will lose all your work on securing your site if you redirect a user from an https page to an http page.
So, could someone please explain to me if I am right or wrong here in the following scenario:
Is it right practice to use https on the login page then redirect him to Admin Page with http, or will this will create a security issue like Session Fixation hijacking, stealing session, etc.?
Or must I keep the Admin Page also in https?
Another side of the question is: will https allow caching of static files?
I have read other articles here but I am still confused as some say 'yes' and some say 'no'; also some say it depends on browser.
In your instance (in only securing the login page with HTTPS) while login details will be protected (e.g. username/password), your users will be susceptible to Session Hijacking.
Whether you use a mixture of HTTP/HTTPS or full HTTPS depends on your situation. Amazon for instance, will use HTTPS for the login, but you'll browse the site with HTTP, but as soon as you go to a sensitive area (Order details screen, change account/password details etc.) it switches to HTTPS and asks you to re-authenticate. Re-Authenticating the user after switching from HTTP to HTTPS is the key to stop Session Hijacking because you're effectively issuing a new Session token. So if a user steals the session token, they still don't have your username/password and can't access your account section.
If the admin area is particularly sensitive then just HTTPS the whole thing. Google found the overhead from using full HTTPS was between 1-5% overhead on the CPU, hardly anything basically.
As for caching static files on HTTPS I'm not sure, but this SO post suggest it'll cache as normal Will web browsers cache content over https
Everything must be used with https. If you switch over to http, everybody can see the content being sent, which means those security issues you mentioned will emerge.
The reason is that you have to identify your client in order to assign access rights in your admin site. One possibility to do so, is sending back a token (some hash or whatever). Depending on the token you know if it's an authenticated client or not. But everybody else does see this token => security issue.
Of course you could use the previous https session to exchange a private key. And use it to encrypt your http stuff somehow. But this is a bad idea, since https does this much more conveniently..
Updated with clarifications
Hello,
When our users go to http://mysubdomain.server.com/login they get redirected to https://secure.server.com/login?subdomain=mysubdomain. So the actual login page is located on the secure.server.com subdomain.
The problem is that if the user logs in with the credentials meant for subdomainA and tells Firefox to remember the password, the browser will autocomplete the login form even if the user visits the login page meaning to log into subdomainB.
Firefox assumes that the login form on secure.server.com/login?subdomain=subdomainA is the same with the one on secure.server.com/login?subdomain=subdomainB.
At first, I thought Firefox remembers passwords based on a combination of the URL and the name attribute of the form, but I've tried changing the name based on the subdomain (name="login-<subdomain_name>"), and it still doesn't work.
How can I make Firefox remember passwords for subdomainA and for subdomainB separately, and not together?
I couldn't quite decipher what your setup is, but you can enable login manager debugging and check what Firefox does. You can also inspect signons.sqlite in your profile to see what pieces of data are stored with the login.
I thought that for web forms it keyed off the form's submit URL, but my memory is shady on this.
[edit]
source (nsLoginManager.js) says it only uses the form's action and the page's URL, and it uses not the action/page URL itself, but (see _getPasswordOrigin) the scheme+host+port combination.
If they're actually entering data into http just to be redirected to https after login, isn't that a bad scenario? You're already sending the most sensitive piece of data unencrypted across the wire.
I believe a better solution would be to redirect them to the https site and do login there...is there something I'm missing with your setup? Do they login again on the secure site?
AFAIK domain name (complete) is the current basis for remembering login. It wasn't always so, though. I'm not sure about protocol or port number, but a.domain.com is different from b.domain.com and domain.com, but same as a.domain.com/somewhere.