Weblate: [Social Auth] Azure AD: "Authentication has been forbidden by server"

Created on 18 Jan 2019  ·  16Comments  ·  Source: WeblateOrg/weblate

Describe the bug
There's no information aside from "Authentication has been forbidden by server" when the sign in request is returned from Azure AD.

I've the debugging log level set to VERBOSE, but can't see any further into as to why I'd get "Authentication has been forbidden by server." when trying to register, or login using Azure AD tenant auth.

The authentication attempt is working (Azure AD processes the login) and the return URL to Weblate looks OK. https://weblate/accounts/complete/azuread-tenant-oauth2/, with the parameters: code, state, session_state.

To Reproduce
Steps to reproduce the behavior:

  1. Setup Azure AD free
  2. Register application
  3. Setup weblate tenant information
  4. Attempt registration/login

Expected behavior
The user is taken to registration form if they match REGISTRATION_EMAIL_MATCH.

Server configuration and status

 * Weblate 3.3
 * Python 3.6.7
 * Django 2.1.5
 * Celery 4.2.1
 * celery-batches 0.2
 * six 1.12.0
 * social-auth-core 3.0.0
 * social-auth-app-django 3.1.0
 * django-appconf 1.0.2
 * translate-toolkit 2.3.1
 * Whoosh 2.7.4
 * defusedxml 0.5.0
 * Git 2.17.1
 * Pillow 5.1.0
 * python-dateutil 2.7.5
 * lxml 4.2.1
 * django-crispy-forms 1.7.2
 * django_compressor 2.2
 * djangorestframework 3.9.1
 * user-agents 1.1.0
 * jellyfish 0.7.1
 * pytz 2018.9
 * pyuca 1.2
 * PyYAML 3.12
 * tesserocr 2.4.0
 * Mercurial 4.5.3
 * git-svn 2.17.1
 * Database backends: django.db.backends.postgresql
 * Cache backends: avatar:FileBasedCache, default:RedisCache
 * Celery: redis://cache:6379/1, redis://cache:6379/1, regular
 * Platform: Linux 4.15.0-1036-azure (x86_64)
question

All 16 comments

I think this means that request back to the OAuth server failed with HTTP 401. I've added some more logging in 5d0d368f3091e5f34a8a9f1fff32513fbc0a8b90 so that it's easier to diagnose (the best approach to get useful debug information is to use Sentry or Rollbar to collect error information).

Hmm, I couldn't find that commit.

If only got the docker image setup -- I assume I can't get access to bleeding edge until next release?
I'm not familiar with Sentry or Rollbar, but I'm assuming as it's docker, that might also be a little tricky?

Tried fiddling with app registration settings on the Azure side, but no luck. It registers a Success in the sign ins.

Sorry I forgot to push it, done that now. You can use both as a service with a free tier which is typically fine for Weblate. See https://sentry.io/ and https://rollbar.com/. The docs for configuring Weblate is here: https://docs.weblate.org/en/latest/admin/deployments.html#error-reporting

I was able to setup Sentry to capture the error now that 3.4 was released. It was configured using the docker parameters as per the documentation.

I'm getting an "AuthForbidden: Your credentials aren't allowed" -- apparently a "Warning" generated by the social_auth stuff. I tried setting and unsetting SOCIAL_AUTH_AZUREAD_TENANT_WHITELISTED_DOMAINS but no change.

HTTPError: 401 Client Error: Unauthorized for url: https://login.microsoftonline.com/<tenant>/oauth2/token

Reading through some of the sentry logs, it seems to be trying to query the anonymous user? Not too sure what I'm looking at here.

SELECT "weblate_auth_user"."id", "weblate_auth_user"."password", "weblate_auth_user"."last_login", "weblate_auth_user"."username", "weblate_auth_user"."full_name", "weblate_auth_user"."email", "weblate_auth_user"."is_superuser", "weblate_auth_user"."is_active", "weblate_auth_user"."date_joined" FROM "weblate_auth_user" WHERE "weblate_auth_user"."username" = 'anonymous'

image

@nijel , could I please confirm the expected workflow for Social Auth?
I assume users can _register_ using Social Auth? I don't need to pre-create the user do I?

Yes users can register using Social Auth, if new registrations are not disabled in Weblate.

Yes users can register using Social Auth, if new registrations are not disabled in Weblate.

Hmm, got them enabled WEBLATE_REGISTRATION_OPEN=1 with no REGISTRATION_EMAIL_MATCH set, so the workflow is inline with what I was expecting...

And getting of anonymous user is expected, because it's the current user until you authenticate.

And getting of anonymous user is expected, because it's the current user until you authenticate.

Fair enough. Thought that might be the case, but was wondering if it somehow picked up the wrong username or similar (thinking it should have had the username details returned from the oauth request).

So what happens is that login.microsoftonline.com refuses to issue OAuth2 token, are both WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY and WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET correct?

They should be -- as the Azure AD workflow is happening correctly (this errors if the Key, Secret or Reply URL don't match), so it's returning to the "complete" endpoint https://weblate/accounts/complete/azuread-tenant-oauth2/.

I tried playing with SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_RESOURCE but no go so far...

Looking at https://github.com/python-social-auth/social-core/issues/140, you might have to change SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID, but I really don't know anything about how this is supposed to work...

Yeah, already setting that -- that's pointing to my Azure AD tenant. Hoping the user from #1821 can help provide some insight on configuration! Thanks for your research and help so far :)

I don't know if I can be of much help.

All I remember doing is following the instructuons on social auth page:

  • created the oauth2 client in azure - that step was tricky since they have two ui's and only one of them is good
  • add the config lines in weblate with client secret and client id

II will try to get the details from the server but I am abit swamped :(.

Thanks for the info :)

I think I'll try recreate the app. There is a new UI again, so perhaps there's some differences there.

I think the manifest file would contain everything configured, but if you get a chance to check please let me know :)

I think I've cracked it -- the Secret key had special characters in it, and was affecting the docker yaml.
I put it in quotes to escape it, which allowed it to go through, but then started using ''s in the secret.

Generating a new secret with less special characters, and it's working fine 🤦‍♂️

Was this page helpful?
0 / 5 - 0 ratings