-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an authentication service to the FFI #820
Conversation
Codecov Report
@@ Coverage Diff @@
## main #820 +/- ##
==========================================
- Coverage 77.99% 77.92% -0.08%
==========================================
Files 92 92
Lines 13900 13936 +36
==========================================
+ Hits 10841 10859 +18
- Misses 3059 3077 +18
Continue to review full report at Codecov.
|
More clippy errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a couple of nits, overall looks sane.
let homeserver_url = client.homeserver(); | ||
|
||
// Create a new client to setup the store path for the username | ||
let client = Arc::new(ClientBuilder::new()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, so you create a Client
with a fake user to get some metadata about the server. Then you set the correct user here. Am I getting this right?
It might make sense to modify the Client
in the bindings to support memory only operation. I guess it isn't that important since the store will only be used once you log in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that's correct, it's totally a workaround 🙈. Jonas and Ben had a conversation around whether the client store should be set at all until after login has succeeded. Amongst other things this would help if the user ID returned by the homeserver differed to what was used to log in.
This all seemed like it was a larger thought than just the bindings to me, so I opted for this for now. However if its something I could address in this PR, would be happy to be given some direction and have a go 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well we used to have an API where you just pass an optional store path to the Client, similarly to what the FFI Client
does. Maybe we should just bring that back, of course only if the sled
feature is enabled.
In any case, I'm not sure what we should do, so let's leave bigger changes around this for another time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, and if it works for you then that's even better.
This PR adds a basic authentication service to the FFI that abstracts away the client until a login has been completed successfully. Additionally it adds
authentication_issuer
property to the SDK client for OIDC detection.Always happy to learn of any changes that would make this into more idiomatic Rust :)