I'm trying to log into the StackExchange network and I receive a 403 Forbidden error after entering my credentials.

I am using Chrome Version 46.0.2490.71 m (completely up-to-date, as of this writing), on Windows 7 x64.

I notice that there appear to be two different avenues by which to log-in, and only one of them seems to be subject to this issue.

Steps to reproduce:

  1. Browse to http://stackexchange.com and click the log in link (in thin black bar at top of page).

screenshot of stackexchange.com homepage

  1. One is then presented with a view that asks him to choose which sign-in method to use. Choose "log in with StackExchange".

screenshot of various sign-in options

  1. Enter login credentials when prompted and click Sign In button.

screenshot of login form

  1. Receive 403 Forbidden response from server.

screenshot of unsightly 403 Forbidden server response

Oddly enough, if I browse to another StackExchange property, such as http://stackoverflow.com, and click the login link that is in the same place (in the thin black bar at top of page), I see a different login page, which looks like this:

screenshot of login page that actually works correctly

When I attempt to authenticate on this page, everything functions as expected and I'm logged-in.

Is this a bona fide bug on the StackExchange side? Or am I "doing it wrong"?

At a minimum, the unsightly 403 error and attendant message should be made a bit more... "user friendly".

UPDATE: I disabled all extensions in Chrome (notice that the ad-blocking icons are gone, next to the URL field), but the behavior is the same:

screenshot of 403 error with all Chrome extensions disabled

UPDATE 2: The behavior is the same in Waterfox v40.0.2 (which is 64-bit Firefox, essentially). Again, the session ID can be seen in the URL, so perhaps an engineer is able to investigate further as to whether this behavior is specific to my public IP address (which is a corporate gateway IP, for what that's worth) or a larger issue.

screenshot of same 403 error in Waterfox

I'm happy to share the full URL with a qualified individual. (I hesitate to post it here, as it may contain sensitive information regarding my identity or account.)

UPDATE 3: An Adaptive Security Appliance appears to be involved. The only headers that are present in the HTTP response (per Chrome Developer Tools) are:

HTTP/1.1 403 Forbidden Server: Adaptive Security Appliance HTTP/1.1 Content-type: text/html Connection: close

How might I troubleshoot this further? Should I reach-out to net-ops on my end?

  • I can't repro this in FireFox 41.0.2 / Win7/x64
    – rene
    Commented Oct 26, 2015 at 20:20
  • @rene Interesting. I'm on Chrome Version 46.0.2490.71 m. You will notice that I have a few extensions installed, so I'm going to disable all extensions and see if it makes any difference. It is also possible that the 403 is specific to my IP address (or a larger block). Presumably, a StackExchange developer can glean more information from the session ID pictured in the screenshot. Commented Oct 26, 2015 at 20:23
  • The behavior is the same with all Chrome extensions disabled, and I updated the original question to reflect this fact. Commented Oct 26, 2015 at 20:27
  • 1
    I find that error page so... non-SE like. It almost looks like a page from a proxy server gets served instead of an SE page.
    – rene
    Commented Oct 26, 2015 at 20:39
  • @rene Great call. I think you are onto something. If I examine the HTTP headers, I see information about Adaptive Security Appliance. I have updated the original question with what limited headers are returned in the response. Is this Adaptive Security Appliance on my network? Or StackExchange's? I guess the real question is why this happens when I log in via stackexchange.com, but not one of the sub-domains. Commented Oct 26, 2015 at 20:46
  • I had a quick search here but I never heard of that appliance in the context of the network stack at SE so for now I assume that is in your network. Unless an SE SysOp tells us otherwise.
    – rene
    Commented Oct 26, 2015 at 20:51
  • @rene I believe that we may be dealing with cisco.com/c/en/us/products/security/… , as we do use these. For now, I'm leaning towards a problem with our corporate network. I don't want to waste anybody's time, so until I can prove otherwise, I will bark up that tree. Thanks so much for your help. Commented Oct 26, 2015 at 20:54
  • [status-norepo] for me too, my SE login based on that page works Commented Oct 29, 2015 at 18:55
  • Thanks for taking a look, Oded and Yummy Unicorn Rainbow Tails. I have little doubt that this is a problem with our network, and as soon as I determine the root cause, I will post the answer and accept it. Your time is sincerely appreciated! Commented Oct 29, 2015 at 19:16

1 Answer 1


I finally determined the root-cause: the Cisco Adaptive Security Appliance that filters our HTTP traffic is configured to prevent access to URLs whose length exceeds a certain threshold. On older ASA models, this length is 1159 characters (presumably single-byte), by default.

Credit to Poonguzhali Sankar for highlighting the root-cause in her 6-year-old post at https://supportforums.cisco.com/discussion/10827126/long-url-not-allowed-asa .

From the legacy documentation:

Enable Filtering of Long URLs

By default, the security appliance considers an HTTP URL to be a long URL if it is greater than 1159 characters. You can increase the maximum length allowed for a single URL with this command:

hostname(config)#url-block url-size long-url-size

Unfortunately, this solution did not apply, directly, because our appliance is much newer.

The appliance technician said the following of the solution that he employed:

The post above is from 6 years ago, and the command is no longer the same; it has you reference the URL length in size, from 2-4KB, now. That being said, the output below reports that there are no blocks due to a long URL.

# sh url-block block statistics 

URL Pending Packet Buffer Stats with max block  0
Cumulative number of packets held:              0
Maximum number of packets held (per URL):       0
Current number of packets held (global):        0
Packets dropped due to
       exceeding url-block buffer limit:        0 <--- (somewhat surprisingly)
       HTTP server retransmission:              0
Number of packets released back to client:      0

What I've done instead is told the ASA to truncate long URLs for HTTP sessions, which effectively sends only the host information, rather than the entire 1200+ character URL, on to WebSense. This was already in place for the HTTPS sessions, just not HTTP.

As noted in the terminal output, I'm a bit surprised that the event count is zero (0) for exceeding url-block buffer limit, but the technician's adjustment did indeed resolve the issue.

Thanks again for all the helpful comments!

You must log in to answer this question.

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