Feature request: handle the System-Token header
#125
Comments
mssola
added a commit
that referenced
this issue
Jul 19, 2022
In order to detect system duplicates, SCC implemented a `System-Token` mechanism in which systems are to report a token that is generated for every request from systems. The Ruby implementation of SUSEConnect stores this into the credentials file for every request. If the response did not contain any token (e.g. first time that a system contacts SCC or upgrading from and older SUSEConnect) then an empty token is stored into the credentials file. All in all, this commit brings this Go implementation on par with the Ruby one when it comes to detecting system duplicates. Fixes #125 Signed-off-by: Miquel Sabaté Solà <msabate@suse.com>
mssola
added a commit
that referenced
this issue
Jul 21, 2022
In order to detect system duplicates, SCC implemented a `System-Token` mechanism in which systems are to report a token that is generated for every request from systems. The Ruby implementation of SUSEConnect stores this into the credentials file for every request. If the response did not contain any token (e.g. first time that a system contacts SCC or upgrading from and older SUSEConnect) then an empty token is stored into the credentials file. All in all, this commit brings this Go implementation on par with the Ruby one when it comes to detecting system duplicates. Fixes #125 Signed-off-by: Miquel Sabaté Solà <msabate@suse.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This header is meant to be saved on the credentials file (
/etc/zypp/credentials.d/SCCcredentials), and each response from scc.suse.com will give you back a new value that is to be saved.Take a look at SUSE/connect#478 for more info.
The text was updated successfully, but these errors were encountered: