Staff

@fred-fred said in Custom theme deployment between environments:

It looks like we can transport with the API using Theme Update Endpoints and sharing environment API keys so one environment can see the next environment to copy the themes over.

Yes, that's what I'd recommend. You could have different API keys for each environment and have the script that promotes the theme pull the API key from a secrets store. Make sure you limit the API key to the themes endpoint.

You also might be interested in this post: https://fusionauth.io/community/forum/topic/1306/parameterizing-themes which indicates how you can have the same theme files point to different resources in staging/prod/dev/etc.

@omryc3 Have you tested the authentication tokens and seeing if the password policy applies to them? I'm not sure myself, but it should be an easy test to run.

It is not possible to have different password rules apply to users in the same tenant, since they are tenant level policies and apply to every user within a tenant.

You could have the users that you want to have no password expiration use OIDC to login against a third party server. (And that server could be a different FusionAuth instance.)

@markus-wild

Hmmm. A few more details would be helpful. Are you using the basic self service registration form? And the mobilePhoneNumber field? Or is it some other field that you are using?

What is the exception you are seeing? Where does it show up? What does the end user see?

Also, what version of FusionAuth are you using?

Thanks!

@fred-fred

Hiya,

In addition to what @maciej-wisniowski suggested, if you have a paid license you can now have application specific themes (one theme per application; if no application theme is specified, it defaults to the tenant).

You can see how that works in the sandbox environment (sandbox.fusionauth.io). I believe that feature landed in 1.27.0.

You can buy a licensed edition here.

@trashmi13

Hiya. You can validate this token using any JWT library, as Id Tokens are valid JSON Web Tokens.

I'm not sure what language you are using, but here's an example for java using the fusionauth-jwt library:

    List<JSONWebKey> keys = JSONWebKeySetHelper.retrieveKeysFromJWKS("https://www.googleapis.com/oauth2/v3/certs");
    
     Map<String, Verifier> publicKeyVerifiers = new HashMap<String,Verifier>();
     for (JSONWebKey key : keys) {
        String publicKey = key.x5c.get(0); 
        Verifier verifier = RSAVerifier.newVerifier(publicKey); // assuming all keys are RSA. You could switch on type as well.
        String kid = key.kid;
        publicKeyVerifiers.put(kid, verifier);
     }
     
     // Verify and decode the encoded string JWT to a rich object
     JWT jwt2 = JWT.getDecoder().decode(encodedJWT, publicKeyVerifiers);
     
     // make sure the aud and issuer are as expected
     if (jwt2.audience.equals("gge44ab3-027f-47c5-bb07-8dd8ab37a2d3") && jwt2.issuer.equals("www.acme.com") && (jwt.expiration.toEpochSecond() > (System.currentTimeMillis()/1000) )) {
    	 // valid id token
     }

Hope this helps.

Seems like a bug, filed an issue: https://github.com/FusionAuth/fusionauth-issues/issues/1503

Release notes: https://fusionauth.io/docs/v1/tech/release-notes/#version-1-31-0
Blog post: https://fusionauth.io/blog/2021/11/22/announcing-fusionauth-1-31/

@adil I'm going to look into this further, but it is possible that the JWT reconcile operation isn't compatible with those other IdPs (in which case the documentation is incorrect). Will let you know what I find in the next few days.

As a workaround, would suggest using the 'complete login' API call as documented in each of those providers individual docs:

https://fusionauth.io/docs/v1/tech/apis/identity-providers/apple/#complete-the-apple-login

https://fusionauth.io/docs/v1/tech/apis/identity-providers/linkedin/#complete-the-linkedin-login

@adil Can you share what your request looks like for the google call that works, please?

@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?