-
Notifications
You must be signed in to change notification settings - Fork 139
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
API Authentication #285
API Authentication #285
Conversation
Stores their name, website, and credentials
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.
👀
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.
I think it could help with readability to have a special type with some parameters, doing by itself something similar to ApiToken.can(), and which could be used as a request guard (so we could do something like fn read_post( [...] , _authorized: Authorization<Read, Post>)
and it would deny request without tests to do by ourself)
use canapi::Endpoint; | ||
|
||
#[derive(Clone, Default, Serialize, Deserialize)] | ||
pub struct AppEndpoint { |
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.
This feel strange to be at the same time data received from Post (with id, client_id and client_secret ignored, as they must be generated by the server) and data returned by the api (with those same field used, and most likely different than what was originally posted if they where). It should either be 2 different struct or at least a struct with FromForm custom-implemented to ensure that
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.
We can't use FromForm
in plume-api, or we would loose all the benefits of canapi.
But I think I may add a Server
/Client
/Both
wrapper type to specify when a field is required and make it easier to check if something has been forgotten.
Or maybe canapi is just a bad idea and we should drop it... 🤔
Filter requests that don't have an API token authorized to read or write a specific scope;
Co-Authored-By: BaptisteGelez <baptiste@gelez.xyz>
beb3d86
to
49e0605
Compare
And remove some warnings about unused parameters
8eb5291
to
1a2ad8d
Compare
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.
There are just a few quick things that should be changed or discussed, and this will be good to go
Only require it when reading draft articles.
App
modelApiToken
modelApiToken
a request guardFixes #275