The tc-accepted rest service now properly returns

if the terms and conditions are not met but the user credentials are OK.

Note: not yet in production. This will happen when this issue is marked Done

But yes, long term, the installer may have some bits which have different subs attached, so we do need to be able to generically support them all.

devsuite MUST use the same model as the cdk - the full RHEL Dev Suite Sub. I have updated this in the download manager - it looks like it was set incorrectly originally to the Red Hat Developers Sub.

If this was incorrectly set all along, it does explain why this issue was occurring.

Red Hat Developers Subscription does not require the additional terms and conditions to be signed, however if you are using the web browser, Keycloak asks you to sign them anyway.

Red Hat Enterprise Linux Developer Suite Subscription requires the additional TCs as well.

IMO you should be able to download all terms and condition models, because all of them are valid options. You just need to do the things right to handle the download. If you still do not understand what to do, please, organize a call where we may discuss it.

CDK and DevSuite have different tc model:

• devsuite - "tcModel":"Red Hat Developers Subscription"
• cdk - "tcModel":"Red Hat Enterprise Linux Developer Suite Subscription"

Should we just update devsuite to have the same tc model as cdk has?

Now my account gets in exactly the same state as reported by Rick Wagner, I can download the installer, but get T&C's error. Workaround is sign in to developers.redhat.com and try to download CDK. This would trigger additional info request

and after I agree on all T&C's Installer Account page works fine.

This confirms Pete's suggestion above about iteration over each download being long term solution for installer.

Installer sends http GET request with basic authentication to tc-accepted rest service the same way it would be sent by browser or any http client, so I think it does not matter where it comes form JavaScript, browser or curl command line.

Does authentication method matter in this case? New account credentials works fine in both cases for tc-accepted rest service and developers.redhat.com.

This specific user has valid credentials obviously, because OpenID auth accepts it and let it go further to 'Addition Action Required' page which requests to sign additional T&C. But res service that supposed to check if T&C's are accepted returns 401 for this user instead of false to indicate problem with T&C's.

I'll just go ahead and accept missing T&C and see what will happen next.

Sounds like https://issues.jboss.org/browse/RHDENG-564 is the right longer term solution (and specifically what Rob was going to implement), and then in the installer we have to iterate through each download and check it can be signed (and if not pull up the correct URL for people to go sign at).

The behaviour of Download Manager is correct. tc-accepted is a rest service and uses basic authentication. The page you use is using different authentication method - OpenID. The tc-accepted rest service was never meant to work with Javascript, because it would require people to pass their user credentials over insecure web.

So if you call it, you get 401 no matter if you have or have not signed the terms and conditions - DM is simply missing user credentials and the correct response for such case is 401.

dhladky@redhat.com, this account has valid credentials, if I supply invalid credentials I get this page below

Problem is developers.redhat.com and download manager behavior is different for nivologd account. developers.redhat.com asks about providing additional information, specifically signing T&C. Download manager returns authentication error instead of false, to indicate T&C's is not signed.

Current registration workflow asks to sign tree items and nivologd user does not have one marked below
.

Is that valid behavior for download manager?