Skip to content

Troubleshooting Login

This guide provides solutions to common login related issues you might encounter.

Login history

Often it is useful to check if and when a user has had a successful login in the past. You can check the Auth0 logs for this information:

  1. Go to the Auth0 Dashboard: https://manage.auth0.com/
  2. Make sure you are in the correct tenant (statista production)
  3. Navigate to "User Management"
  4. Search for the user by email
  5. Click on the "History" tab to see login history

If you don't have an individual user's email because the client is connected via an identity provider (e.g. SAML, OIDC) you can also search the Auth0 logs directly:

  1. Go to the Auth0 Dashboard: https://manage.auth0.com/
  2. Make sure you are in the correct tenant (statista production)
  3. Go to "Authentication" -> "SAML" (or "OIDC" depending on the IdP)
  4. Find the connection for the client and click on it
  5. Copy the "Connection ID"
  6. Navigate to the "Monitoring" -> "Logs" section
  7. Search for connection_id:"<Connection ID>" to see all logins via that connection

General Issues

EC2 Shibboleth servers logs

Our EC2 Shibboleth servers export their logs to Datadog which can show hints of what is failing.

User hits paywall

Symptoms:

  • Client logs into the system (via username password)
  • Client gets redirected to /registeruserdatapaywall and prompted for an additional username/password login

Diagnosis Steps:

  1. Check the table userProductFeatures with the idUser being equal to the account number
  2. See if the product feature '225' is enabled for them
  3. Have the CSM disable the product feature
  4. If the user was using IP-Login before, check if the isWalledGarden column from the users table is disabled.

Name showing in dropdown list on campus page

A client asked if we can change the name that is showing in the dropdown list on the campus page.

Normally the connection name shows in the dropdown list. And this cannot be changed.

However at Auth0 a connection can also have a display_name. This cannot be edited via the UI, but only via the management API.

A CURL to change it looks like this:

curl -X PATCH https://statista.eu.auth0.com/api/v2/connections/con_fabcRXMlEvt0XVXYZ \
  -H "Authorization: Bearer ${AUTH0_API_TOKEN}" \
  -H "Content-Type:  application/json" \
  -d '{"display_name": "Put desired display name here"}'

You can retrieve the AUTH0_API_TOKEN manually from the Auth0 API explorer:

Auth0 -> Applications -> APIs -> Auth0 Management API -> API Explorer

After changing the display name, you need to wait for memcache to pick up the new value. It might take up to 20 hours.

You are not allowed to log in

Upon logging in via the client's login page, the system redirected them to the following page with the message: “You are not allowed to login.”

Solution: the issue comes from the fact that the account has an "Email not confirmed error". The email address needs to be set to "confirmed" (e.g. in the CRM).

Screenshot of "You are not allowed to log in" error

Note: This error page only appears for legacy auth methods that rely on Auth0 id-login. For other Auth0 login methods a remix-sso error page would be shown in that case.

Client is logged in but cannot access premium statistics

Symptoms:

  • Client is logged in (via partnerlogin) but when going to premium statistics, it shows the paywall

Common Solutions:

  • Deactivating and then re-activating the access
  • Resetting product rights

IP-Login

IP is not being recognized

Symptoms:

  • Client is not logged in when they come to our site
  • Client tells us that their IP is not recognized

Diagnosis Steps:

  1. Let the client go to https://www.statista.com/ipcheck and verify the client is recognized (it will identify the user in the "IP-User:" line)
  2. Check Auth0 logs for IP logins from that IP: https://manage.auth0.com/dashboard/eu/statista/logs?q=185.4.96.2 (where the q= parameter is the IP of the client)
  3. Have the CSM check in the database that the IP is configured in the "IP access" area and that "Activate IP access" is checked
  4. Check production database (table "usersIP") if IP (notated in CIDR ranges) is present
  5. Check if the CIDR range in the table "usersIP" is not actively being used more than once (for different customers)
  6. Check requirements for users: https://github.com/CPE-Orga/platform-sso-services/blob/main/src/ip-login-synchronizer-service/services/mysql-service.ts#L53-L56
  7. Check for errors from the "sso-ip-login-synchronizer" Lambda: https://app.datadoghq.eu/logs?query=service%3Asso-ip-login-synchronizer&agg_m=count&agg_m_source=base&agg_t=count&cols=host%2Cservice&messageDisplay=inline&refresh_mode=sliding&storage=hot&stream_sort=desc

Common Solutions:

  • Add IP-address to the CRM and wait for sync (happens every 30 minutes)
  • Remove IP-address from the CRM and wait for sync (happens every 30 minutes) in case the IP was in there multiple times for different customers

Legacy OIDC

Login fails with error message on oidc login page

Symptoms:

  • Client tries to login via legacy oidc and gets an error message "Unfortunately, an error has occurred. We are working to resolve this issue. Please try it again." legacy-oidc-error.png
  • The URL is the legacy oidc url for the customer, e.g. https://www.statista.com/login/openidconnect/cambridgeshire-county-council
  • User is not logged in

Diagnosis Steps:

  1. Check Datadog logs for hints, be aware that these errors are logged in info level: Filter DD logs for service:configfrontend @callerStack:"StatFrontendBundle:OpenIdConnectService:log" env:prod
  2. If it states "wrong issuer" check the legacy oidc connection for the customer in the configfrontend, see Legacy OpenId for file details. For Azure AD as IdP the issuer is usually in the format https://login.microsoftonline.com/{tenant-id}/v2.0.

Shibboleth SSO

Unknown or Unusable Identity Provider

Sometimes users will provide us with a wrong Entity ID. In this case our Shibboleth server will fail to look up the IdP and error with this message:

Unknown or Unusable Identity Provider

To verify that indeed the Entity ID is the problem we can go to the Edugain website and use their search function to look for the Entity ID the user provided us with:

If they gave us the correct Entity ID we will find the IdP in the search results as shown below:

Edugain Search

If you receive an updated Entity ID from the user you can verify it with the WAYFless Generator.

Some German speaking unis are complaining that they land on the English platform and not on the German one (although we set it correctly in the CRM).

For Shibboleth the language depends on the Browser language. So when the client's browser is set to German, they will land on the German platform.

In Chrome this can found in the language settings, where German needs to be put to top.

University is requesting the Statista Entity ID for their Shibboleth connection

Our shibboleth entityID is: https://shibboleth.statista.com

OpenAthens

Forbidden Error when accessing via OpenAthens

Symptoms:

  • Client hits an error page when trying to access via OpenAthens redirector link.

OpenAthens

Diagnosis Steps:

  1. Check if the scope of the user is part of the OpenAthens federation. This can be done here: https://met.refeds.org/.

Common Solutions:

  • If the university is not part of the OpenAthens federation, there is no solution at the moment. We can't provide access to these users unless they are part of the federation. We are offering the client to use Shibboleth.

Users in specific IPs land on the Statista homepage without being logged in

Symptoms:

  • Client clicks on the OpenAthens redirector link and lands on the Statista homepage without being logged in.

Diagnosis Steps:

  1. Check the network requests in the browser's developer tools to see if there are any requests to Auth0 or Remix SSO.
  2. If there are no calls to Auth0 or Remix SSO in the network logs, check if the client has Redirector IP bypass zones enabled in their OpenAthens settings. (This configuration is located under Preferences > Redirector)

Solution:

  • If the client has the Redirector IP bypass zones enabled, they need to exclude Statista from the list.

OpenAthens Redirector IP bypass zones

Last updated: March 24, 2026 at 10:39
By: Axel Tetzlaff