@lionel-selosse

Thanks for the feedback; please remember to keep your comments constructive.

https://fusionauth.io/community/forum/topic/1000/code-of-conduct?_=1662488626348 https://fusionauth.io/docs/v1/tech/admin-guide/technical-support#community-members

If you have a bug to report, you can do so below

https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

Or you can log a bug report directly to the repo in question

https://github.com/FusionAuth/fusionauth-example-asp-net5-react/issues

However, I have included a response to your forum post for further consideration.

Thanks!
Josh

@sullivan

Thanks for the question. The reason that you are not seeing anything in this view is you need to have a docker logger set up. FusionAuth will write system logs to STDOUT. This output must be picked up by a logger in Docker (which can then be reviewed). By contrast, if you were running FusionAuth in a non-containerized environment, this view would show you current system logs.

https://docs.docker.com/config/containers/logging/configure/

Hope this helps!

Thanks,
Josh

@maciej-wisniowski That actually work

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.