@leandro-menagonzalez

I will mark this resolved as we discussed this out of band.

https://fusionauth.io/docs/v1/tech/installation-guide/cloud#restoring-from-backup

Thanks,
Josh
FusionAuth

@johnathon

These are the steps FusionAuth takes to check whether a password contains special characters:

Convert the Java String to a char[] (a char is a 16-bit unicode value in Java) Check each character c to determine whether it is a special character using
!Character.isAlphabetic(c) && !Character.isDigit(c) If any character in the string returns true for the above check, we consider it to contain a special character

@mark-0

I have not done this, but from looking at the Fastify JWT library, it looks pretty straight forward:

https://github.com/fastify/fastify-jwt#options

Since there's no Fastify FusionAuth integration, you need to pass the public and private key if you want to verify and sign the JWTs, respectively. Since FusionAuth is creating the JWT, in theory you could just pass the public key of an RSA keypair, since you'll never need to sign the JWT (haven't tested that though).

To add the keys to FusionAuth, you'll want to use Keymaster: https://fusionauth.io/docs/v1/tech/core-concepts/key-master

Hope that helps.

@mrstudyfirst I was recently researching this and decided to test Outseta to cover the majority of these requirements and get up and running quickly and affordably at first, and then Rewardful later for affiliate functionality.

@yurochkoyura I can't think of any way to implement this via FusionAuth configuration alone.

Seems like a cool feature request, though. Please consider submitting a feature request and if there's community support, we'll look at putting it into the roadmap: https://github.com/fusionauth/fusionauth-issues/issues

From a scan there, though, it looks like this may be part of this long standing issue: https://github.com/FusionAuth/fusionauth-issues/issues/1

So if you want to add a comment or vote that up, that'd be helpful to us as well.

@nick said in Customers accounts vs internal company accounts for a SaaS app:

Hello,

I'm trying to understand how FusionAuth would work best for a SaaS app with two kinds of accounts: customers and internal admins.

The internal company logins are e.g. sales people, developers, customer services, etc. They need to be able to access an internal admin portal, and in addition, a sandbox customer account for testing.

It seems like it could be convenient to let internal admins share one user account and an app-switcher to toggle between their admin-view and their customer-view.

Is it a best practice? Is it unsafe in any way?

Thanks,

You should look into FusionAuth.io to see if it fits your needs. It has a more adaptable model than the big SaaS solutions and could meet your needs both now and in the future.

@atakan You shouldn't remove the main features that current users have already paid for if you're switching your app to a subscription-based business model. For instance, after you introduce a subscription model for new customers, allow customers who have already purchased a "full game unlock" to continue having access to the full game.

This, in my opinion, applies to Notability, and if enough users raise awareness of it, it might be possible for us premium users to continue using it without a subscription.

@dan 160ms

@eirikur That is awesome, thanks so much for sharing your settings.

Hi @dan, thanks for your answer. In our case, we are accessing directly to the FusionAuth instance and we started to get this error after the last upgrade to 1.36.8.

I will fill an issue.

Thank you very much,
regards

@ltyl I think that you could use a proxy that would set the X-Forwarded-For: header to a known bogus value. If you put that in front of FusionAuth, it should happily set every ip address to that value.

https://fusionauth.io/docs/v1/tech/admin-guide/proxy-setup#headers-to-set

This will mean that you can't use IP based access control lists, however.

@dee-lalwani Hmmm. That is almost a 2 year old post, so things could definitely have changed.

I might scan the release notes for relevant changes: https://fusionauth.io/docs/v1/tech/release-notes

Either way, if you see behavior that is different, you can open a feature request. We rank future work in a variety of ways, but popular feature requests from the community are definitely high on the list.

FYI, providing step by step repro steps for this feature would be most helpful, as well as your current version.

You could also spin up a version from Sep 2020, maybe Version 1.19.8, and see if it has the behavior you want.

Depends on the use case. If you need a user management tool with OAuth, SAML and all the bells and whistles, then “yes!”

If you need LDAP connected to servers or wifi, then “no”.

@akash-0

Hi!

FusionAuth does not currently have such an API. If you'd like to request this feature, you can file an issue in the fusionauth-issues GitHub repository that includes details for your use case. Developers can show their support/interest for a feature by giving it a thumbs up reaction. We use this to plan the FusionAuth product roadmap.

Thanks,
Spencer

Yes. Here's the PR merging it:

https://github.com/SocialiteProviders/Providers/pull/877

Thanks to https://github.com/danilopolani for adding it.

Should show up here: https://socialiteproviders.com/about/ once this has been merged: https://github.com/SocialiteProviders/website/pull/28

@bryan-odaly

The http://www.w3.org/2000/09/xmldsig#rsa-sha1 algorithm has been removed as of Java 17.

More details:
https://github.com/FusionAuth/fusionauth-site/issues/1202
https://fusionauth.io/docs/v1/tech/release-notes#version-1-32-0

This error means you are using an SAML v2 IdP that is signing their Authn response with RSA-SHA1. The best way to solve this is to change the signing configuration if you have access to that, or request the owner of that IdP sign their response using a more secure, modern algorithm.

@chalk Did you get this sorted out or are you still looking for guidance?

@theogravity-sb

Hiya,

You should be able to specify the property to search when using the queryString.

username:test will exactly match users with that username

username:tes* will match any users that have a username that starts with tes.

Does that help?

@johnathon

Also, if you are using Graal, using let and const will not be supported until version 1.37.0.

https://github.com/FusionAuth/fusionauth-issues/issues/179