Closed ghost closed 9 years ago
Oops, scrubbed it too much. In get_graph there is a line missing: token = fb_account(user).socialtoken_set.get()
Would it help if on top of:
SOCIALACCOUNT_PROVIDERS = {'facebook': { 'SCOPE': ['email']}}
you could do:
SOCIALACCOUNT_PROVIDERS = {'facebook': { 'SCOPE': 'path.to.callable'}}
Where callable points to a method of the form def get_scope(request)
?
Or, perhaps more simpler & cleaner -- simply add a def get_provider_config(self, request, provider)
to the social account adapter ?
Hi,
Either approach seems to be missing the contextual information for which additional scope is requested. Hence the use of a decorator where the required extra permissions can be declared per view. The underlying design issue seems to be that allauth assumes global scope, and regardless of whether we use a callable or adapter hook, we need to intercept view execution, and do some OAuth ping-pong for additional permissions with a 'next' parameter pointing to the view.
Also, what happens if the user declines additional permissions? The difference to the standard login flow is that the user is already logged in, and only the view will fail. This is apparently not correctly handled by the OAuth flow, as the view is called regardless of whether the user grants or declines the extra permissions.
This is handled in the current version of the decorator hack by passing a sentinel via 'next', and redirecting to a custom error URL if the permission is not granted, e.g. like so:
@fb_permission_required( settings.FB_PUBLISH_RIGHTS, on_fail=reverse_lazy( 'permfail'))
def my_view( request):
pass # Do something useful here
Thoughts?
-D
I'll have to give this some more thought... but I think this is the proper approach: the /accounts/facebook/login/ (and the other OAuth2 ones) should accept a GET parameter via which scope can be passed along. These views already take a "process" GET parameter indicating how to process the login. Next to "login" (process=login) and "connect" a third option, namely "redirect", seems required.
Just starting to tackle this issue as well. Any additional/new thoughts on the matter?
Closed in 9c14ef7619d6cdf09a78a5024f14b7c621e94398
Hi @pennersr , do you have a link to the relevant part of the doc on this ? (Does it exist ?) I have the scope in the settings. So unsure on how to preserve it as the default scope in that path.to.defaultscope and override it with path.to.extrascope
This is a feature request, or an oversight on my part.
My application relies on Facebook login, and in accordance with FB guidelines, it starts with a minimum set of permissions. When a user triggers an action that requires additional permissions, the app should request them.
As far as I can see from the readme / google / bug reports, the OAuth scope is hard-wired in the settings.
So, I came up with this:
Is there a more elegant way to achieve the same result with allauth? And if not, any chance of having dynamic OAuth scopes added?