3

I can't login to SE chat using Tor Browser Bundle. Even tho I'm logged in SE. Seems like chat.stackexchange doesn't read the cookies written by stackexchange?

And when I click on login button, and try to login via stackexchange, it takes a while and then goes to http://chat.stackexchange.com/login/global-fallback and returns this error:

No referer was present - this may be due to a browser setting

is there any way to get around this issue? and if not, where should I file a bug report?

6
  • 2
    Bear in mind that your cookie isn't sent over SSL when logging into SE and chat, so a malicious exit could log in as you after you've logged into chat via TBB.
    – user5
    Commented Oct 30, 2013 at 13:12
  • Yeah that's another issue with SE which has been promised to be fixed soon. However, I still feel much safer to use Tor to get on here
    – mrphs Mod
    Commented Oct 30, 2013 at 16:53
  • 1
    I've let the SE team know of this issue. It's certainly weird considering you can login fine to tor.SE, meta.SE and area51.SE
    – Megan Walker Mod
    Commented Oct 30, 2013 at 21:05
  • The error message is pretty clear: Your browser didn't send a refer(r)er, so it's probably disabled in the browser settings.
    – balpha StaffMod
    Commented Nov 4, 2013 at 6:31
  • I'm using Tor Browser Bundle and it works just fine everywhere else on the web. It's also working fine all around the SE, except for chats. My guess is chat.se is not using an standard way to handle the cookies and redirections...
    – mrphs Mod
    Commented Nov 4, 2013 at 7:21
  • It's not just TBB; I've been having the same problem in Chrome when AdBlock is enabled. Pausing AdBlock, then logging in, then un-pausing AdBlock worked for me finally.
    – Andrew Lott
    Commented Dec 12, 2013 at 10:07

1 Answer 1

Reset to default
1

If you're using the browser bundle and it's configured to prevent you from sending certain headers (e.g. referrer, accept, etc) - you can try using a web based proxy for instances when you need to get around that, if you don't want to (or can't) enable those headers.

I can't reliably test this but you might be able to get around it in this fashion, although web sockets and (quite possibly) third party cookies won't work - so you'll hit our 'fallback' for logging in, but it should be functional for you.

I hit a similar problem at a friend's office, where he was behind a load balancing firewall that spread traffic across a dozen DSL circuits, and was set up with one of the most draconian (stripping / blocking both outbound and inbound traffic) policies I've ever seen. It took a few tries, but I was able to finally log in.

Unfortunately, I don't have a lot of other advice to offer - this is the first time I've seen this come up for someone using the browser bundle.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .