Fixed ac integration tests (CADC-14851)#196
Conversation
pdowler
left a comment
pdowler
left a comment
There was a problem hiding this comment.
Is it still safe/viable to run these tests against an ac service deployed with an existing ldap (eg devldap)? It's hard to see if there is anything destructive but I think not...
The setup in ConfigUsers looks good.
I'm inclined to follow the instructions in the src/intTest/README and test, but using the existing devldap.... safe??
ac/src/intTest/README
Outdated
| - ac-priv-user.pem : certificate file for privileged user capable of augmenting subject | ||
|
|
||
| Other resources: | ||
| - $RPS/RsaSignaturePub.key file used to sign cookies on the service |
There was a problem hiding this comment.
service needs the private key to sign (technically ac creates signed tokens and access repurposes them as cookies)
How do the tests pick one user in .netrc when there can be multiple entries? Just by looking for one that matches the target server name??
There was a problem hiding this comment.
Made the pub key description clearer. It is the pub key corresponding to the key that signs certs.
Yes, in .netrc it's picking the one corresponding to the target server name.
There was a problem hiding this comment.
hmmm, my .netrc would have my own (pdowler) entry, possibly even for my local deployments... maybe look at the VosiCapabilitiesTest in cadc-test-vosi (reg.git) because that also makes use of .netrc to test token auth (and that's used in many services)
There was a problem hiding this comment.
I'm using my own entry because I don't know other passwords and there's no easy way to distribute them off band. It's only used for login and password resets tests and the latter is not actually changed.
There was a problem hiding this comment.
but if you are running a disposable ldap server container, don't you hjave to add your own account to it? And put the right password in .netrc? Or do you use the .netrc entry to create that account as well? (I didn't look into the details of the login test)
There was a problem hiding this comment.
The account creation (and account requests creation) tests are currently skipped because they can't be undone. With a local disposable LDAP deployment we won't need the .netrc mechanism because the ConfigUsers could use the certificates to automatically create and configure accounts as need it and it would set the passwordAuthUser attribute required in the tests.
I've been running the tests so at least the config users don't seem to be affected. I'm not sure if it still leaves junk behind in devlap. |
2 participants
No description provided.