Skip to content

Error accessing dashboard #2252

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dbr opened this issue Mar 6, 2020 · 5 comments · Fixed by #2384
Closed

Error accessing dashboard #2252

dbr opened this issue Mar 6, 2020 · 5 comments · Fixed by #2384

Comments

@dbr
Copy link

dbr commented Mar 6, 2020

I logged in, and tried to click on Dashboard link under my username. It directs to
https://crates.io/me
and gives the following error. Same happens with "Owner Invites" page in same menu, but Account Settings works

Ember Data Request GET /api/v1/crates returned a 403 Payload (application/json; charset=utf-8) [object Object]

  r@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:3958:19
r@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:3961:100
handleResponse@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:4027:17
handleResponse@https://crates.io/assets/cargo-122a2a85ee957cc7845ce8a377e9170f.js:6:340
r@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:1925:9
o@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:3997:14
ajax/</<@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:4033:8
ajax/<@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:4033:19
_@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:3640:12
y@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:3638:128
invoke@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:3219:139
flush@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:3211:74
flush@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:3222:292
_end@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:3273:9
V/this._boundAutorunEnd@https://crates.io/assets/vendor-d56f71d6bbd0a4e94bf420b72ba26f0e.js:3231:605
@jtgeibel
Copy link
Member

jtgeibel commented Mar 6, 2020

Thanks for the report @dbr. I'm not able to replicate this on my machine in production or staging right now. Can you capture the JSON response data through the browser tools for the /api/v1/crates response? Also, look at the query string, I have ?following=1.

The only obvious way I see for that endpoint to generate a 403 response is when an invalid letter parameter is passed, however that doesn't seem to be applicable here.

@dbr
Copy link
Author

dbr commented Mar 6, 2020

Strange - while I was looking at the JSON responses, this seems to have corrected itself..

From https://crates.io/api/v1/crates?following=1 I was getting this response with an error 403:

{"errors":[{"detail":"must be logged in to perform that action"}]}

At the same time https://crates.io/api/v1/me was giving the expected response of

{"user":{"id":2962,"login":"dbr", ...

Then, for no obvious reason, reloading the problematic crates URL then started giving a valid response of

{"crates":[],"meta":{"total":0,"next_page":null,"prev_page":null}}

Maybe related, I did notice that while clicking on some other links ("Other Invites" etc) earlier I did become logged out, but, only sometimes.

However, all seems to be working okay again for me - could be closed unless you think it's worth investigating any further. Thanks! :D

@jtgeibel
Copy link
Member

jtgeibel commented Mar 7, 2020

Thanks for the follow up info. The 403 is definitely related to some auth issue. (I grepped for the wrong thing earlier.)

We should definitely leave this open, I'm seeing other requests in the logs matching status=403 crates?following=1. (Probably a few hundred requests going back the last month. I'd need to pull down archives to try to find a start date.)

@locks and @Turbo87 do you think it's possible a request is being made somewhere before the login completes? I'm not ruling out the backend either, and will look into adding more logging data here.

@Turbo87
Copy link
Member

Turbo87 commented Mar 7, 2020

our current auth code is unfortunately a bit hard to follow so I can't rule out the possibility of a race condition somewhere. I haven't noticed any such issues myself yet, but if the request fails like that for @dbr then it seems quite likely that that is the problem.

I do have a few refactorings for the auth code in mind already anyway, so hopefully those would fix this issue too 😅

@carols10cents
Copy link
Member

My first thought was a browser or plugin issue, but I looked at the user agents in the logs for the status=403 crates?following=1 query and I'm seeing a pretty wide variety of user agents across mobile, OS, and browser. Ex: Chrome 80 on Android 10, Firefox 73 on macOS (High Sierra), Firefox 73 on Windows 10, Chrome 74 on Linux, Safari 13 on iOS 13.3 Apple iPhone.

bors added a commit that referenced this issue Mar 12, 2020
Add some error chaining to log more on auth failure

cc #2252
r? @pietroalbini
bors added a commit that referenced this issue Apr 3, 2020
…r=carols10cents

Serve more static files from nginx

Serve more folders containing files with hashed filenames directly from
nginx with a max expiration date.  Additionally, some unhashed static
files are allowed to be cached for up to 1 day.

These changes serve as a workaround for an authentication issue.
Currently `conduit-cookie` includes a `Set-Cookie` header in every
backend response.  During the authentication steps, the popup window
requests static assets such as `favicon.ico` and `cargo-{hash}.png`.
If these assets are served by the backend, they will echo whatever
cookie was sent in the request.  Therefore, there is a race between the
request to `/api/private/session/authorize?...` and requests for these
static assets.  If a request for one of these assets is sent before
authorization is complete and the response arrives after successful
authorization, then the stale cookie will be stored again by the
browser, overwriting the contents.

I've opened conduit-rust/conduit-cookie#12 to track the progress of the
proposed long-term solution.  This commit should be sufficient to fix
the behavior for now and should reduce the number of requests for these
static assets (due to improved caching).

Closes #2252
r? @carols10cents
@bors bors closed this as completed in 45c7511 Apr 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants