Login successful, but browser not allowing it
-
It just shows the same screen and blanks out the fields, yeah. There's no errors at all, which is what I was hoping for. I suppose I could try to look at apache logs on the pfsense box itself?
-
Only happens with Chrome. Any plugins of note?
-
Adblock, Adblock Plus, MightyText, and LastPass. I tried disabling all of them and restarting Chrome, but no luck. Clearing cache is the only thing that resolves it, but only temporarily.
Note: If I open a 'incognito' window, it works.
-
Something to do with cookies maybe?
-
Just a guess, but are you using https for pfSense? If so, might be worth atry to switch back to http for testing.
Perhaps an SSL complaint inside chrome or one of the addons?
-
Yes, it might have to do with cookies, not sure why now as opposed to the previous 8 months I've had this up and running… and yes, I'm using https for administration.
-
Your Content Settings are all at default or recommended?
-
Content settings in Chrome are default, I've never mucked with them. I've now uninstalled every extension in Chrome except my password manager, which I'm not disabling to fix this issue. I've had to delete cache and cookies more times than I am comfortable with ONLY to resolve this issue. If this doesn't solve it, I'll just use FF or an Incognito window, not sure how to troubleshoot this any further.
-
So I've now run into the same issue with another pfsense installation in Chrome as well. And it wouldn't be so bad if it was just on one computer. Is there some sort of logs I can look at on the backend to try to debug this problem? I'm about ready to pull my hair out. Looks like the lighttpd.log is binary, so I can't read that…
I've run into it once or twice in Firefox, but restarting the browser fixed it there. Am now running Version 38.0.2125.24 beta-m (64-bit) but it also happens on my Mac, and on my work laptop as well. Chrome is pretty much straight out now. And switching certificates from my wildcard to the self signed that the install comes with makes no difference. I can give someone a username if they'd like to help figure this out... but I'll take anything I can get at this point.
Anyone? Please?
Edit:
Upon doing some inspection with Fiddler, it looks like my Chrome install is doing something odd with cookies... I see this in my Chrome session:Request sent 150 bytes of Cookie data:
drmt_cs=w3trhWYyob3yFWvgSpzQ1GNw%2C%2C; PHPSESSID=14c8aa25b8269d0e4da32d5f56676a65; cookie_test=1409391525; PHPSESSID=1361ae9d80d41e78ed2b509ed397e727
Whereas with Firefox (Or a incognito Chrome session), I see:
Request sent 66 bytes of Cookie data:
cookie_test=1409391955; PHPSESSID=df69291fcaa88d76a0bed7862c3bed72
2nd Edit: I've now cleared cache once again, and uninstalled/reinstalled Chrome. Would appreciate any tips if someone has one while I wait for this problem to occur again.
-
After four years and Chrome gone from 38.x to 70.x this problem is still here to make us frustrated.
I ran into this problem when changed webConfigurator access protocol from HTTPS to HTTP.
Has anyone solved this? -
@roberz said in Login successful, but browser not allowing it:
Has anyone solved this?
Dono - but Chromo developers are not watching this forum. They have their own forum.
A typical solution would be : treat Chrome as any young browser : don't use them for anything serious. Chrome is more a "transfer your info and more to Google" tool.
Most of us learned our lessons very well when we had to deal with the early years of IE.Bt : I have nothing against Google as a search engin.
-
I am experiencing this EXACT issue on EVERY Chrome browser I have tried. Firefox and Edge (shudder) work just fine. It's just Chrome.
To recap: When logging in, the user is redirected back to the login page. pfSense logs a successful login.
Why it's happening: It's a cookie problem, and it looks like it's a Chrome cookie problem.
Looking at the headers being sent and received, on the original POST occurring when the login form Sign In button is pressed, the result is a 302 redirect to / (root), with a new cookies being set. The important parts of the response header coming from pfSense:
Location: /
Pragma: no-cache
Server: nginx
Set-Cookie: PHPSESSID=f7fb1c144db0c4869cec2c2ccb6c5b8f; path=/; HttpOnlySo pfSense has accepted our credentials, logged us in, and redirecting us to the home page. The 302 redirect tells it to go to the root (/) location, gives us a new cookie named PHPSESSID, which is applicable to the root path, so it knows who we are, and that we are logged in.
So the browser does what it is told: it requests the root document. HOWEVER....the new cookie which was just transmitted to us in the 302 redirect response, is NOT sent by Chrome to pfSense. As a result, pfSense has no idea who we are when we request this root document, and so instead just shows us the login page again. The login page sends a NEW cookie:
Pragma: no-cache
Server: nginx
Set-Cookie: PHPSESSID=b9259f186112b134d0bec1b87853de61; path=/; HttpOnlyIf we try to log in again, this new cookie ALSO is not sent as part of the form POST.
So what is going on? Why is Chrome refusing to send cookies? I suspect it is because we're accessing pfSense by IP address. This is an ongoing problem with Chrome, where it will not send/save cookies when accessing a site by IP:
https://bugs.chromium.org/p/chromium/issues/detail?id=3699
I fixed this by adding an entry to my local DNS which points to the IP address of my pfSense box. You could accomplish the same thing by adding an entry to your HOSTS file. You will also need to add the hostname to System/Advanced/Admin Access/Alternate Hostnames, if HTTP_REFERER enforcement is not disabled.
Doing this fixed the problem for me.
-
@ITFlyer said in Login successful, but browser not allowing it:
This is an ongoing problem with Chrome, where it will not send/save cookies when accessing a site by IP:
https://bugs.chromium.org/p/chromium/issues/detail?id=3699That issue was solved and closed in 2013 .
Captive portals are (also) detected by the OS these days.
When the network link comes up, cable or Wifi, the OS set's up IP related stuff, using static parameters or a DHCP negotiation.
Right after that a HTTP request is thrown out (a recent forum post enumerated them all). This implies also that DNS should work.
If a single Success word comes back as a html page, then the OS knows that the connection is "open".
Check for yourself with the Apple iOS using his URL http://captive.apple.com/
If the result NOT Succes, then the OS open a (default) browser or notifies the user that they should open a browser.True, if the browser does nothing but opening a default home page like https://www.google.com then they are out of luck : https request can't (never !) be intercepted, and you'll be hitting the wall. I guess all browsers also throw out a simple http request first - or a ping, etc. these days first to check ...
What I can't explain ; if you set up the captive portal with a trusted certificate by enabling the https portal login, the login process becomes even more flawless.
https, so you have to have a certificate which means that you have to setup a host and domain override for the captive portal IP, like
our-portal.company.tld instead of using an IP like 10.0.0.1
the first looks better anyway, the visitor will see a certificate that his browser trust.Note : https login doesn't mean the portal can intercepts requests like https://www.google.com that will always be a no-go.
I'm using the captive portal in a hotel, which means that thousands of clients (some if not most of them do not know what captive portal is ! ) drop in and they all connect to our captive portal without issues.
Needless to say that these clients bring along with them the latest iPhone, or a very ancient Samsung, PC's with Windows XP etc. -
I will just add here that I am not seeing this and I connect to many different pfSense boxes everyday using Chromium by IP address. Whatever it is you're hitting seems more nuanced than just that.
Steve
