Posts made by robotdan

We'll be adding native support for TLS in an upcoming release. See this GitHub issue for reference.
https://github.com/FusionAuth/fusionauth-issues/issues/1996

In the UI you can select "Special character" to require at least one special character. If anyone is looking to understand which characters will satisfy this requirement read on.

If you view the tooltip or the API - you’ll see the configuration is actually for non-alpha-numeric.

https://fusionauth.io/docs/v1/tech/apis/tenants#create-a-tenant

tenant.passwordValidationRules.requireNonAlpha
Whether to force the user to use at least one non-alphanumeric character.

So instead of limiting this to a specific set of special characters, we allow it to be any character that is not a unicode alphabetic and not a digit. In this way, we do not artificially limit the entropy of the password by saying you must use one or more characters for a finite set of "special characters" as you may be used to seeing on some login forms.

@chekikeja

You'll need to use WSL v2 or wait for the update which will include a native Windows start script using PowerShell.

See https://github.com/FusionAuth/fusionauth-issues/issues/1848

@greggwonderly

When using the Docker image you'll need to either use PostgreSQL or build the MySQL JDBC connector into the image.

We've updated the Docker Hub description and the Docker install instructions to make this clearer.

https://hub.docker.com/r/fusionauth/fusionauth-app
https://fusionauth.io/docs/v1/tech/installation-guide/docker#limitations
https://raw.githubusercontent.com/FusionAuth/fusionauth-containers/master/docker/fusionauth/fusionauth-app-mysql/Dockerfile

This is a current limitation due our current understanding of the license under which the MySQL JDBC connector is released by Oracle.

@hwallenstone @chekikeja @greggwonderly

Sorry for the delay here, I've opened a GH issue to identify the cause of this and resolve ASAP.
https://github.com/FusionAuth/fusionauth-issues/issues/1862

@dev-2

Resolved in version 1.36.7 via https://github.com/FusionAuth/fusionauth-issues/issues/1654.

https://fusionauth.io/docs/v1/tech/release-notes#version-1-36-7

@utahtwo Currently this requires two different configurations. We initially tried to do it all within one IdP, but each mode requires different configuration and has unique security constraints. It seemed simpler for all involved to make them separate IdP configurations.

If there is a use case that breaks due to this design decision, please open a GitHub issue and outline the use case so we can better understand your needs. Thanks!

@stephen Thanks for the update.

That is correct, if you do provide a trustChallenge on the Two Factor Start API, it must be used in along with the trustToken.

This allows you the option to bind a trustToken to a particular request.

Are you indicating that it now works as you expect, or that you did not provide a trustChallenge during the Two Factor Start API, and it is still saying it is required when completing the Change Password API? In your example you only show you are sending a loginId, so if that is the case let me know.

@utahtwo I believe this is resolved in 1.36.0, if you can upgrade see if that solves it for you.

https://fusionauth.io/docs/v1/tech/release-notes

@stephen

When the Change Password API returns 400 indicating that trust is required, you'll need to obtain a trust token.

{
  "generalErrors" : [ {
    "code" : "[TrustTokenRequired]",
    "message" : "This request requires a Trust Token. Use the Start Two-Factor API to obtain a Trust Token required to complete this request."
  } ]
}

To obtain a trust token, complete a Two Factor login.

1. POST /api/two-factor/start
2. POST /api/two-factor/login

The completion of the Two Factor Login will return a trustToken value in the response body. This token can be used to complete the Change Password API.

If you want to scope the trustToken returned by the Two Factor Login request for use by the Change Password API, you may provide a trustChallenge in the request body on the Start API. When you do this, the same value must be provided when you use the trustToken on the Change Password API. In this way you can ensure that the trustToken may only be used for the intended purpose.

It looks like the APIs may not have this example outlined, we'll review the doc and see what needs to be updated.

@joshua Can you try and recreate this one to ensure we don't have a bug?
@hamza Have you configured client authentication as required in your application, or only required when not using PKCE?

@dan

This may also be related to our usage of PKCE. I think there is a fix for this exception in the latest version of FusionAuth

[1/Apr/2022:17:39:00] 2022-04-01 5:39:00.406 PM ERROR io.fusionauth.app.action.BaseOAuthCallbackAction - Returned Exception
[1/Apr/2022:17:39:00] java.lang.NullPointerException: Cannot invoke "String.length()" because "s" is null

@sandrinho said in Cluster install:

pgbouncer

I don't know that pgbouncer will work with FusionAuth. I don't know much about it, but from reviewing their FAQ it looks like the application or perhaps just the SQL client needs some additional configuration to utilize prepared statements (which we use a lot of).

https://www.pgbouncer.org/faq.html

If you can get it working, let us know, but it wouldn't be something we'll have much of any expertise with.

Tracking here: https://github.com/FusionAuth/fusionauth-issues/issues/1519

@james-black

Thanks for letting us know, this is a bug. To work around it, add this to the top of startup.sh:

CURL_OPTS="-fSL --progress-bar"

@engineering-0 said in Cann't import_users in Django:

wZzgYlJnnTiJ/HaS1XSx+uCsmC3To5FMQ1yMGqX//8s=

I don't know why .. if I Base64 encode your salt DxFgAtoVimgE to RHhGZ0F0b1ZpbWdF it works. Not sure why this would be the case, the value looks to be Base64 encoded already.

  @Test
  public void django_test() {
    PBKDF2HMACSHA256PasswordEncryptor encryptor = new PBKDF2HMACSHA256PasswordEncryptor();
    String hash = encryptor.encrypt("0p;/)P:?", "RHhGZ0F0b1ZpbWdF", 150_000);
    assertEquals(hash, "wZzgYlJnnTiJ/HaS1XSx+uCsmC3To5FMQ1yMGqX//8s=");
  }

Can you try importing the salt pulled from Django after Base64 encoding the value, and see if that works?

@admin-3

I think so. See the "Managed domains" configuration in the SAML v2 IdP.
https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/#create-a-saml-v2-identity-provider

Adding one or more managed domains for this configuration will cause this provider not to be displayed as a button on your login page. Instead of a button the login form will first ask the user for their email address. If the user’s email address matches one of the configured domains the user will then be redirected to this login provider to complete authentication. If the user’s email address does not match one of the configured domains, the user will be prompted for a password and they will be authenticated using FusionAuth.

@joseantonio

Thanks!! This may be a bug, we’ll open an issue to track.

All of the new IdPs added in 1.28.0. Twitch, Steam, Xbox, Sony PSN, and Epic Games.