Several consumers of Panda are exposed to internals that maybe could be avoided #153
Comments
rtyley
added a commit
to guardian/login.gutools
that referenced
this issue
Aug 9, 2024
This is pretty minor change, but due to guardian/pan-domain-authentication#147 and guardian/pan-domain-authentication#153, there are a couple of changes required: * imports for `PublicKey` *
rtyley
added a commit
to guardian/login.gutools
that referenced
this issue
Aug 9, 2024
This is pretty minor change, but due to guardian/pan-domain-authentication#147 and guardian/pan-domain-authentication#153, there are a couple of changes required: * imports for `PublicKey` * `settings.privateKey` becomes `settings.signingKeyPair.getPrivate`
rtyley
added a commit
to guardian/login.gutools
that referenced
this issue
Aug 9, 2024
This is pretty minor change, but due to guardian/pan-domain-authentication#147 and guardian/pan-domain-authentication#153, there are a couple of changes required: * imports for `PublicKey` * `settings.privateKey` becomes `settings.signingKeyPair.getPrivate`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If a consumer calls the current
PanDomain.authStatusmethod, or directly references 'PublicKey', it's possibly exposed to internals of Panda that we might be able to avoid.The above examples are calling
PanDomain.authStatus, which means they express in their own code the assumption that Panda uses a single PublicKey to perform verification. That assumption will be broken by #150 - at that point the consumer code can be updated to cope with that, but maybe even better would be for the consumer code to make no assumption at all- could we just ask Panda "Is this cookie valid?", without having to reference a 'public key' at all...?The text was updated successfully, but these errors were encountered: