Force reauth

[jesusbv]

Description

If the header for registry cache is set, create an empty file (remote IP-system_login as a name) in /var/lib/rmt/tmp/registry/cache/ to use as a cache

Use the cache file together with the expiration date to auth registry access

Once the cache time has expired, remove cache file

Fixes # (issue)

Change Type

Please select the correct option.

• [ ] Bug Fix (a non-breaking change which fixes an issue)
• [X] New Feature (a non-breaking change which adds new functionality)
• [ ] Documentation Update (a change which only updates documentation)

Checklist

Please check off each item if the requirement is met.

• [X] I have verified that my code follows RMT's coding standards with rubocop.
• [X] I have reviewed my own code and believe that it's ready for an external review.
• [ ] I have provided comments for any hard-to-understand code.
• [ ] I have documented the MANUAL.md file with any changes to the user experience.
• [X] RMT's test coverage remains at 100%.
• [ ] If my changes are non-trivial, I have added a changelog entry to notify users at package/obs/rmt-server.changes.

[jesusbv]

Draft while I add the tests

[digitaltom]

Could we add to the README of the registry engine an explanation explaining the process and the reasons for this cache mechanism? Maybe with step-by-step commands showing how the cache will get set, invalidated etc? I'm a bit lost on this :dizzy:

[rjschwei]

I do not quite understand, can you please provide the connection between this PR and #1124?

In #1124 the token that the client (docker or podman) use to authenticate expires after 8 hours from last_seen_at, why do we need additional handling?

Based on #1124 when the token expires then a new login would be required, i.e. the user either accesses the repository path or runs the new auth command we will provide with the client code.

Sorry, I am confused.

[jesusbv]

No need it, as we do not want to force reauth, last_seen_at approach is OK

Re open as we need a way to verify the instance data for the registry cache

[rjschwei]

This approach, which is similar to what we do for repository access with in principal certainly work. That said it appears the scope of the topic and the requirement is not covered by the changes. It appears like another "throw something at the wall and hope it sticks" approach.

While we are under time pressure we can also not produce a quality implementation by approaching the problem with no plan. Based on the conversation in #1124 and the comments in this PR please present a comprehensive plan that covers the requirements. Then we'll proceed to the implementation phase.

This PR for example neglects the "needs to be configurable" requirement. It also does not cover the "8 hours after the last full verification" requirement. With this implementation what would happen is that if I run "zypper up" on the client 7 hour and 59 minutes after the last access when the cache file was created I would still have to run the client side re-auth script because the cache handling here is completely disconnected from the repository access path.

Please develop an understanding of the requirements the we have, which are really only 2

1.) configuration of the expiration period 2.) default 8 hour access after the last full verification of the client system

once you have an understanding of the problem space for these requirements present a plan how to go about the implementation and then implement in reasonably small parts that are self contained that can be related back to the plan.

[jesusbv]

Closing this PR in favor of

1140

1141

1142

1143