Add header for reauth purposes

[jesusbv]

• When refreshing the credentials server side, add a header to explicitly set the registry cache file

[schaefi]

Just nitpick on the test, the code looks good to me 👍

I'm missing details about the motivation of the new header field as well as where it's been used or what consumes it. I guess this information is in some other API documentation ? I again reviewed only in terms of code not in terms of functionality as a whole

[rjschwei]

On the server side we, i.e. people working on the registry as part of RMT project have currently 2 PRs pending, SUSE/rmt#1124 and SUSE/rmt#1128. As commented in 1128 I do not understand the need for it given 1124. Also X-Registry is too generic.

My understanding based on 1124 in the RMT project is as follows:

When the client, docker or podman, come to visit they will send a token. The code in 1124 will check if the last_seen_at time is more then 8 hours ago and if so the token will be rejected. Thus access is denied, meaning the user has to re-auth. When the activation() function is called the system via the repository path will not be in the cache and therefore a full verification will take place. This will update last_seen_at and thus the next access of the registry if it is less than 8 hours later will work.

Meaning this change is not needed.

[jesusbv]

On the server side we, i.e. people working on the registry as part of RMT project have currently 2 PRs pending, SUSE/rmt#1124 and SUSE/rmt#1128. As commented in 1128 I do not understand the need for it given 1124. Also X-Registry is too generic.

My understanding based on 1124 in the RMT project is as follows:

When the client, docker or podman, come to visit they will send a token. The code in 1124 will check if the last_seen_at time is more then 8 hours ago and if so the token will be rejected. Thus access is denied, meaning the user has to re-auth. When the activation() function is called the system via the repository path will not be in the cache and therefore a full verification will take place. This will update last_seen_at and thus the next access of the registry if it is less than 8 hours later will work.

Meaning this change is not needed.

I understood that the behavior on 1124 was correct until

The idea is to expire the token after 8 hours no matter how often the system comes to visit in those 8 hours

meaning we would need to force a reauth, depending on that comment or, in other words, whether we are OK having the expiration of the access updated by any access of zypper (again, I understood we are OK with that but the comment states different behavior) then this PR would be needed or not

[jesusbv]

Clarified that last_seen_at is enough for granting access to the registry, we do not need this change