AUR web shows that I'm not logged in

When I click on the link of a package that shows the notification email (the one you receive when the notifications of a package are activated) the page shows me the menu as if I am not logged in:

But if I copy and paste the link manually in the browser it does show the right menu (logged in):

In addition, the menu shown when I click directly on the link (in email) is the old one, not the new one, which is this one:

Maybe it is a problem with the language as I have Spanish selected and the menu shown when I click on the link is in English.

Firefox 98.0.2
Google Chrome 100.0.4896.60

The problem still occurs even if I change the interface language to English.

It's quite annoying, isn't anyone going to do anything?

what's your software stack here?

• OS
• Web Browser

OS: Arch Linux
Web Browser: Google Chrome and Firefox

Okay. So, it's hard to tell from these gifs because I'm not exactly sure when it starts or when it ends, but:

1. Going 'Back' on firefox, by default, does not refresh the page.
2. You seem to be illustrating the issue by (a) going back then (b) clicking login without refreshing.
3. This is always going to be the case after logging in and going back, because the page you see when you press 'back' is still displaying the old state before logging in.

For example, if you:

1. Are logged out
2. You login successfully
3. You press the back button after logging in successfully, bringing you to the state of (1).
4. You refresh the page, which then updates its state to your current authentication state.
5. You are logged in.

How login state works is via HTTP COOKIE. If that HTTP COOKIE is not sent (or the cookie sent does not match what exists in the database) in any particular request, then that request could not and will not be authenticated. Off the bat, this is likely the reason that (This also happens when for example using duckduckgo's "!aur" feature, something I use quite often. reported by @kattjevfel) occurs; the lack of a valid AURSID HTTP COOKIE being sent through the proper channels.

I'm having trouble reproducing a state where this occurs in my local session (or on aur.al) for me, personally. So, I'm having some issues even being able to experience what you believe is an inconsistent login state. This makes it very hard to troubleshoot at all, and without that, I basically have to take your experience illustrated at face-value.

In this repository, there is a Bug description template that can be used for issues. That template (https://gitlab.archlinux.org/archlinux/aurweb/-/issues/new?issuable_template=Bug) outlines what we really need for a bug issue so that we can have enough information to triage; I do ask that you include those details in this issue. The Reproduction section is pretty much the most important there aside from Description of the problem.

I would really ask that you do not use gifs to describe or show "reproduction," as these demonstrate some things, but they can be crafted in such a way that it shows a reproduction of an issue that doesn't actually exist (because we aren't seeing the reproduction from point A (non-existent) to point Z (producing the bug).

If we can gather enough information to be able to reproduce this, then we can actually take a serious look at the problem.

In any case, thanks a lot for reporting anything at all.

I'm working now on producing some documentation regarding exactly how aurweb deals with AURSID, including the AURSID cookie's requirements, criteria and how its used within the database to lease out sessions and verify them per request. We have no single source-of-truth for how web authentication works at the moment, and this would come in very useful for clients of the AUR and for people who may run into issues with their clients interfacing with the system. I'll keep this thread updated on that progress.

At the current time, clients running into issues like this have no way to tell exactly why they may be running into issues, short from completely diving into following trails through git and through the HTTP data, which is terrible in my book.

This also happens when for example using duckduckgo's "!aur" feature, something I use quite often.

added triage label

added scopebug label and removed triage label

assigned to @jocke-l

changed milestone to %August release 6.1.0

OK. So, for a closure here:

The issue with OP's post and @kattjevfel's comment here both correlate to the same underlying issue (in the case where OP is using a web-based mail client). Our use of Secure cookies was way too secure for other origins redirecting to the AUR. The cuplrit here, was Samesite=Strict.

All other Arch websites use Samesite=LAX; there is not much reason to go otherwise at this point given we've run into this issue here through the use of Strict. Of course, this likely affects many more sources than what are mentioned here, so this should help many things out overall in terms of login state.

There is a merge request up at !518 (merged) which will be merged into master shortly and brought out at the end of the month with 6.1.0. Thanks @jocke-l!

Also, thanks to the folks here keeping this problem up on the board. Without the previous understanding of how to reproduce the issue, it was kind of easy to let sit while working on other things. This kind of push really makes it obvious that it's a serious issue people are waiting for a fix on; helps a LOT!

closed with commit 4303086c

mentioned in issue #325 (closed)