Open richardonrails opened 4 years ago
With how the gem is in 2.5.0, I think you also need to remove the entire skip_info
section of the README, as it appears that option is no longer used at all.
https://github.com/ginjo/omniauth-slack/tree/master#skip_info-boolean
@richardonrails @ginjo finding myself in a similar scenario after an upgrade to 2.5.0.
At the moment I can only gain access to the user email address through:
env['omniauth.strategy'].access_token.authed_user.get('/api/users.identity').parsed
Any advice on a better way to access the authorizing user's email? I like the new approach to the flexible, progressive info hash in principle, but I'm a little lost as to how to use it.
Am I doing this right? Or am I missing something?
I'm working on something new and have been playing with this gem before and after this 2.5.0 update
I see now the Auth hash is pretty barebones:
Some misc feedback/questions:
info
fields listed here even if not required, such as email, nickname, first_name, last_name of the user.info
section? Is that typical in OmniAuth (I've never worked with other providers before) but it seems surprising based on my reading of schema since there's a separate section forcredentials
andraw_info
already. And even if you don't include the Access Token object ininfo
, it's still available viarequest.env['omniauth.strategy'].access_token
already, right?info
section of the Auth Hash, or is it best practice to have theinfo
section only contains fields listed inschema
and to put everything else inextra
?In my case I'm trying to allow Sign in with Slack but also grabbing/storing some additional information about their team from users.list. Slightly confused regarding putting e.g. my
users.list
API call in theStrategy
, theOmniauthCallbacksController
, orUser.from_omniauth
. Also trying to plan for other providers besides Slack. This is what made me think it was odd to put non-standard fields in theinfo
section of AuthHash, but I'm not sure.