Performance, Scalability and Architecture

Andreas Grabner

Subscribe to Andreas Grabner: eMailAlertsEmail Alerts
Get Andreas Grabner: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: DevOps Journal

Blog Post

Recursive Browser Redirect Loops | @DevOpsSummit [#DevOps]

A spike in traffic was caused by an implementation issue between our authentication service and our download role-check logic

Performance Impact of Recursive Browser Redirect Loops

100% Coverage
I just recently wrote a blog about BOTs causing unwanted traffic on our servers. Right after I wrote this blog I was notified about yet another "interesting" and unusual load behavior on our download page which is used by customers to download latest product versions and updates:

If you see such a load behavior you typically assume that you just released a new product version or maybe an update to our agents and many people are downloading it like crazy. Unfortunately that was not the case. The spike in traffic was caused by an implementation issue between our authentication service and our download role-check logic. It resulted in a browser of one of our customers to go into an endless redirect loop between these different authentications and download pages, which caused several thousand HTTP Requests per minute.

Spotting the "Single Browser Gone Wild"
The first thing I wanted to know was which users are currently downloading our software. We use dynaTrace UEM (want to evaluate on your app? start here!) which tracks every action of every single visitor on our pages. The interesting finding was that there weren't large numbers of users trying to hit the download page. Instead, there was a single visitor that caused that traffic spike. The following shows the dynaTrace Visits dashlet highlighting the one user from North America using a FF31 requesting the same Single Sign On Page more than 5000 times in a couple of minutes:

Root Cause: Incorrect Handling of User Roles
Looking first at User Action showed me that the user was correctly redirected to the Single Sign-On Page that we have in our system. He entered username and password and hit next. Then I explored the next User Action PurePaths to find out what happened next. It turns out that the user who successfully logged on (username captured as part of the PurePath) didn't have any of our internal user roles assigned that we use to manage privileges such as download, open a support ticket, etc.

After the login page redirected back to the Download page, that page redirected back to login as it was missing the download role privilege. The login page was then automatically reposted by the browser which started the endless redirect loop between the login page and the download page.

For more insight click here for the full article

More Stories By Andreas Grabner

Andreas Grabner has been helping companies improve their application performance for 15+ years. He is a regular contributor within Web Performance and DevOps communities and a prolific speaker at user groups and conferences around the world. Reach him at @grabnerandi

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.