New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 669467 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

LogDog fails with 401 auth error if I manually change the url

Project Member Reported by primiano@chromium.org, Nov 29 2016

Issue description

TL;DR repro:
1) Open a logdog page (I am logged in) -> works
2) change the log path a bit (s=chrome/blah)
3) The subsequent XHR that is fired is missing the authorization:Bearer  header and fails with a "Auth Error"

Full story:
I am looking at some logdog output for perf bots, e.g.,
https://luci-logdog.appspot.com/v/?s=chrome%2Fbb%2Fchromium.perf%2FAndroid_Nexus5X_Perf__3_%2F2705%2F%2B%2Frecipes%2Fsteps%2Fmemory.top_10_mobile_stress%2F0%2Flogs%2Fjson.output%2F0#
everything works fine. I am signed in.

I then did change the url to see the output of some previous build. I did that by tweaking the URL and changing the 2705 part in the url with 2701.
When I did that I got an "Auth Error" message (although I am still signed in).
However at this point if I sign out and in again I can fetch 2701.

So, if I want to scrape the logs looks like I have to sign out and in again every time, which is inconvinient

I looked into more details:
When a request fails I see in the devtools console that the POST to https://luci-logdog.appspot.com/prpc/logdog.Logs/Get gets a 401
The key of the problem is that the subsequent requests (the ones that fail when I change the URL) are missing the header
authorization:Bearer <redacted>

in the XHR. And that is definitely what causes the 401 -> Auth Error in the UI
 

Comment 1 by d...@chromium.org, Nov 29 2016

Owner: d...@chromium.org
I think this is a crappy race between the auth widget, which works by sending an event *sometime* after authentication happens, and the LogDog client code, which tries to respond to that event by retrying if it previously failed b/c of 401.

I'm actually in the process of rewriting this code base, and I think I've solved this particular problem in the rewrite. I should have it pushed in the next day or two.

Comment 2 by d...@chromium.org, Dec 5 2016

Status: Fixed (was: Untriaged)
I did a major rework of the auth workflow. I believe that this is fixed. Let me know if you see it again.

Sign in to add a comment