-
Notifications
You must be signed in to change notification settings - Fork 53
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
Stop returning extra information in GitHub result #100
Conversation
See #71. New `credsExtra` keys: - `accessToken`: so you can make your own follow-up requests - `userResponseJSON`: so you can get more information out of the request we already made (you just have to parse it yourself) Removed keys: - `access_token`: renamed to `accessToken` - `avatar_url`: can be re-parsed - `email`: requires your own request to `/emails` - `login`: can be re-parsed from `userResponseJSON` - `location`: can be re-parsed, was not always present - `name`: can be re-parse, was not not always present - `public_email`: can be re-parsed, was not not always present Also re-orders arguments between default and scoped to allow better partial application -- taking advantage of API breakage already.
New keys: - accessToken - userResponseJSON Removed keys: - battleTag
New keys: - accessToken - userResponseJSON Removed keys: - email - login - avatar_url - access_token - name - location
Removed keys: - charName - charId - tokenType - expires All can be recovered by re-parsing userResponseJSON.
Also removes the ability to parse a custom identifier. See the module documentation for a workaround.
731d2d8
to
ef16a1e
Compare
Adds some safety to the stringly-typed keys we're standardizing on.
- It may not be JSON (thought it always is now) - The JSON suffix should be used only when it is (such as in getUserResponseJSON)
I decided to store the raw response at Also, I'm starting to see a slightly better data Provider = Provider
{ pName :: ProviderName
, pToOAuth2 :: ClientId -> ClientSecret -> OAuth2
, pFetchUserResponse :: Manager -> OAuth2Token -> Either String ByteString
, pParseCredsIdent :: ByteString -> Either String Text
}
something :: YesodAuth m => Provider -> ClientId -> ClientSecret -> AuthPlugin m
something Provider{..} clientId clientSecret =
authOAuth2 pName (pToOAuth2 clientId clientSecret) $ \manager token -> do
-- Assumes we adjust authOAuth2 to use Either, not exceptions
userResponse <- pFetchUserResponse manager token
userId <- pParseCredsIdent userResponse
pure Creds
{ credsPlugin = pName
, credsIdent = userId
, credsExtra = setExtra token userResponse
} I think I'll branch from this and try that out, as a replacement for #92 |
src/Yesod/Auth/OAuth2.hs
Outdated
-- | ||
getAccessToken :: Creds m -> AccessToken | ||
getAccessToken = AccessToken | ||
. fromJustNote "yesod-auth-oauth2 bug: credsExtra without accessToken" |
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.
It's a bummer that we have to use fromJust
here. Is this because Yesod.Auth.Creds
doesn't have a type parameter, so we have to use stringly typed data for the "extra" bits? Would it be worth trying to change this in Yesod.Auth
?
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.
Also, this is not necessarily a bug, right? If somebody authenticates with username/password and then calls getAccessToken
with those creds, that will compile and crash?
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.
Would it be worth trying to change this in Yesod.Auth?
I'm not really sure that would work. Even if it were Creds e m
, for some extras type e
, that e
couldn't be plugin-specific because it must be the same across all plugins in use. Maybe I'm missing something clever though.
Also, this is not necessarily a bug, right? If somebody authenticates with username/password and then...
You're absolutely right; great catch. I think I lean towards making this Maybe
now. I thought there was strong guarantees a value would be present, but non-oauth2-plugins is way too likely.
Nice to see some cleanup and simplification here. |
Even though it's "guaranteed" that values will be present because we set them, nothing stops end-users from using these functions on Creds values created by other plugins! Since that seems common, it would be irresponsible of us to remain so unsafe.
@pbrisbin Great stuff, really looking forward to this change! |
@@ -51,3 +61,22 @@ authOAuth2Widget widget name oauth getCreds = | |||
AuthPlugin name (dispatchAuthRequest name oauth getCreds) login | |||
where | |||
login tm = [whamlet|<a href=@{tm $ oauth2Url name}>^{widget}|] | |||
|
|||
-- | Read from the values set via @'setExtra'@ | |||
getAccessToken :: Creds m -> Maybe AccessToken |
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.
It may be more convenient for users to use Either String
for all the get*
functions. For example, that would let users combine them monadically without writing their own conversions between Either String
and Maybe
.
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 don't know that I follow your reasoning: I think we can't really predict what Monad the user will want to be in, so I don't know that Either
would fit any better at call-sites than Maybe
(they'll almost certainly be in Handler
99% of the time)... But I can get behind Either
for this because it retains information users could choose to silence when in Maybe
(e.g. hush
), vs the current way where the user would have to invent information when in Either
(e.g. note
) -- so 👍
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, on second thought I'm not sure. Having these return Either
feels like if Map.lookup
returned either: that'd be silly because there's only one way it can fail.
I think I'm going to keep this for now.
See #71.
New
credsExtra
keys:accessToken
: so you can make your own follow-up requestsuserResponseJSON
: so you can get more information out of the requestwe already made (you just have to parse it yourself)
Removed keys:
access_token
: renamed toaccessToken
avatar_url
: can be re-parsedemail
: requires your own request to/emails
login
: can be re-parsed fromuserResponseJSON
location
: can be re-parsed, was not always presentname
: can be re-parse, was not not always presentpublic_email
: can be re-parsed, was not not always presentI'll start going provider by provider now.