Skip to content
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

Automatic configuration of Content Security Policy form-action for Social Auth #12321

Closed
michael-smt opened this issue Aug 23, 2024 · 3 comments · Fixed by #12322
Closed

Automatic configuration of Content Security Policy form-action for Social Auth #12321

michael-smt opened this issue Aug 23, 2024 · 3 comments · Fixed by #12322
Assignees
Labels
enhancement Adding or requesting a new feature.
Milestone

Comments

@michael-smt
Copy link
Contributor

Describe the problem

The stricter Content Security Policy since Weblate 5.7 requires careful configuration of the CSP_FORM_SRC when using social authentication providers, because some browsers block redirects after a form submission.

Describe the solution you would like

It would be nice if enabling a social auth provider would also automatically set the appropriate form-action Content Security Policy header values.

For example when WEBLATE_SOCIAL_AUTH_AUTH0_DOMAIN is configured it could be automatically added to WEBLATE_CSP_FORM_SRC.

Describe alternatives you have considered

Describe the required setting of CSP_FORM_SRC in the social provider documentation based on the experience from hosted.weblate.org.

Screenshots

No response

Additional context

Depending on the provider (Auth0, possibly also others) there might be additional redirects to other authentication providers, these could not be automatically configured.

@nijel nijel added this to the 5.7.1 milestone Aug 23, 2024
@nijel nijel added the enhancement Adding or requesting a new feature. label Aug 23, 2024
@nijel
Copy link
Member

nijel commented Aug 23, 2024

The intention was to handle that automatically, but the code doesn't cover all the cases:

# Third-party login flow extensions
if request.resolver_match and (
request.resolver_match.view_name.startswith("social:")
or request.resolver_match.view_name in {"login", "profile"}
):
for backend in get_auth_backends().values():
# Handle OpenId redirect flow
if issubclass(backend, OpenIdAuth) and backend.URL:
form.add(urlparse(backend.URL).hostname)
# Handle OAuth redirect flow
if issubclass(backend, OAuthAuth) and backend.AUTHORIZATION_URL:
form.add(urlparse(backend.AUTHORIZATION_URL).hostname)

PS: There is also #12302

PS2: I think in both cases it would be addressed by using authorization_url() method instead of AUTHORIZATION_URL atribute.

@nijel nijel self-assigned this Aug 23, 2024
nijel added a commit to nijel/weblate that referenced this issue Aug 23, 2024
Do not use attributes, but rather rely on methods which will apply
configuration and other sources for building the URL.

Fixes WeblateOrg#12302
Fixes WeblateOrg#12321
@nijel nijel closed this as completed in 45e558c Aug 23, 2024
Copy link

Thank you for your report; the issue you have reported has just been fixed.

  • In case you see a problem with the fix, please comment on this issue.
  • In case you see a similar problem, please open a separate issue.
  • If you are happy with the outcome, don’t hesitate to support Weblate by making a donation.

1 similar comment
Copy link

Thank you for your report; the issue you have reported has just been fixed.

  • In case you see a problem with the fix, please comment on this issue.
  • In case you see a similar problem, please open a separate issue.
  • If you are happy with the outcome, don’t hesitate to support Weblate by making a donation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Adding or requesting a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants