Draft Authentication API #128
Conversation
jakewins
force-pushed
the
1.0-basic-auth
branch
from
21084f2 to
dee1f22
Compare
| @@ -67,6 +72,7 @@ private Config( ConfigBuilder builder ) | |||
|
|
|||
| this.encryptionLevel = builder.encruptionLevel; | |||
| this.trustStrategy = builder.trustStrategy; | |||
| this.authToken = builder.authToken; | |||
There was a problem hiding this comment.
The reason we didn't add AuthToken to Config was that that makes having a default config kind-of pointless unless we have add a defaultConfigWithAuthToken factory method.
There was a problem hiding this comment.
But isn't that what we have - Config.build().withAuthToken(..)?
There was a problem hiding this comment.
Isn't connecting to a URL with AuthToken the most common thing todo with a driver? Why does a user have to care about setting up a config to achieve that goal?
There was a problem hiding this comment.
Actually, yeah you're right. I'll change it.
|
Also since we only have two classes in it and they need to be fairly easy to find it feels like we should move everything from the |
|
@boggle hmm, I'm concerned about the number of things in that namespace - but as per our discussion today and your point above, this thing is something every driver user will use, meaning it makes sense to put it top-level. If we add more complex functionality later (eg. expand back towards the full object model of the underlying model you outlined) we can add that in a security package. |
- This keeps the same model - principal, credential, token - as originally proposed, but only exposes the concrete parts of the model as required to satisfy a minimal use case. This should be suitable to build upon as need arises for end users.
jakewins
force-pushed
the
1.0-basic-auth
branch
from
dee1f22 to
506829a
Compare
|
On that note, I'd love to separate the driver API into a part shared between connector and driver and a driver specific part. Perhaps that would help a bit with this. |
|
@boggle IMO we shouldn't do that unless we decide to make the Connector API layer public, then it'd make sense to have classes that are shared between them in a third component, agreed - although IMO I think I'd prefer a clean separation, so the Connector layer has it's own representation of what an AuthToken is, but maybe that is overly separatey. |
|
I was more thinking about types like Session and Value that might be shared. We need to sort out dependencies between driver, api, connector, and product. |
|
I disagree the concrete classes should be shared - while they share the abstract concepts, a Session is exposed in a different way on the connection layer than on the end-user layer. Same for But - this is all just my subjective opinion, like with so many other things :p In any case, I think that's orthogonal to this PR, lets keep exploring the API layering tho. |
NOT READY FOR MERGE!
This is a draft of a new driver API for authentication support