Yes, you can do this.

There are a couple of different approaches, they both require a bit of glue code.

You could create a user in FusionAuth with a name like anon-<uuid>@example.com and a known random password. Then create a JWT for that account using the login API. Add info to that account, then if/when the user registers, transfer that account info to the new user. You could even update the email address of the anon-<uuid>@example.com account and reset their password. This would be accomplished via the user API.

An alternative approach is to use the Vend JWT API to create a JWT for your anonymous user. This can look like anything, it's entirely freeform. When the user registers, you can take the info referenced by that JWT and transfer it to the new user.

If these don't meet your needs, feel free to open a GitHub issue with a specific use case.

Different people use various items. You can do direct partnerships, as I've seen our vendors do with Duo, or you can roll your own ADFS, as I spoke with a company yesterday that was doing. If you're comparing options, I'd also look at Okta.

Go talk to the people who make identity products and ask them to sell it to you. It appears that you have no idea what you're asking, so it's either that or hire a consultant to tell you.

@cedric-baiker

Can you confirm what is failing when you attempted this? In other words, do you receive any error information in the system or events log?

Thanks,
Josh

@cyril-feraudet

I believe that you may be looking for this documentation below

If you are building your own login page:

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

If you are using the identity providers that ship with FusionAuth on our hosted pages

https://fusionauth.io/docs/v1/tech/identity-providers/google

Hope this helps!

Thanks,
Josh
FusionAuth

@8mapta1 Thanks for the question.

I might need some context to be better able to assist. But generally, when you are opening an iframe, you will need to direct the actions to this window and the parent window from which it opened.

Can you confirm how you are doing this?

A quick search revealed a few tips, which depending on context may, or may not apply to your situation.

https://www.ramanean.com/how-to-do-a-redirect-in-parent-window-using-an-iframe/ https://www.edureka.co/community/83545/how-to-redirect-parent-window-from-an-iframe-action

Thanks,
Josh

@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