Yes, you just need to activate Reactor using your license key.

Note, though, that the MAUs of your non-prod instances will be counted in determining the total monthly active users. Depending on the user counts, that could push you over a threshold and increase costs. We've talked about ways to mark servers as 'non-prod' but nothing has been implemented.

Hmmmm.

... Detail: view verus_users depends on table old_identities ...

I'm not familiar with the verus_users view and am not sure why that would be in the FusionAuth database. As far as I can tell, that isn't a standard part of the FusionAuth data model.

Did someone at your organization perhaps create a view to get access to the FusionAuth data? If so, you'd need to remove that view manually to perform the upgrade, then recreate it later.

Hope that helps.

Hiya,

It looks like this is being tracked in a github issue as well: https://github.com/FusionAuth/fusionauth-issues/issues/813

Thanks for providing more details.

Have you tried modifying the fusionauth-app.cookie-same-site-policy to None? It defaults to Lax. The cookie should be set to Secure as long as you are serving it from an https URL. That has some security ramifications you should be aware of:

None used to be the default value, but recent browser versions made Lax the default value to have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.

But may be worth exploring to see if it solves your issue right now. If you pursue that in production, make sure you research the security consequences.

I looked in the github issues for https://github.com/openid/AppAuth-Android/ but didn't see anything mentioned. You might want to see if you can narrow it down and file an issue there, since it appears to be an android chrome issue.

I'd also try to see if google sign in works fine from android chrome directly (not using your application, just the native browser) as that might help focus on whether the issue is in the AppAuth-Android code, your app implementation, Android Chrome or elsewhere.

You could also see if any error messages are shown in the fusionauth logs; if so please share them.

Also, if quick turnaround times for support are crucial to you, I'd suggest one of our paid plans with support: https://fusionauth.io/pricing Doing so guarantees turnaround time and engineering team access, as opposed to best effort community support. We understand that won't work for everyone (one of the reasons the community edition is forever free) but I wanted to mention that as an option.

I'm not quite sure I follow.

Do you mean using FusionAuth as the identity provider and connecting these applications using OIDC or SAML?

You can’t. You have to create another API key.

If you want to keep the same value, you could copy the value, delete it, and then recreate with the same value and set the tenant you want.

Hiya,

It's hard to know what's going on without a few more details ?

Are there any logins or other activity happening? Have you modified any of the default settings? Are you running everything (database, fusionauth, elasticsearch) on the t2.small server?

There isn’t a single table in the db really. Configuration exists there, and in tenants, applications, etc.

Sure can. Thanks,

In this situation, the user can login with either their username test or their email address test@example.com (as long as they use the correct password for the account, of course).

This link is probably what you are looking for:

https://fusionauth.io/docs/v1/tech/themes/#handling-failures

Hi @david-0 ,

I understand your frustration. We're thinking about ways to ameliorate this issue.

And you aren't alone. Here are a couple of open github issues:

https://github.com/FusionAuth/fusionauth-issues/issues/751 (kind of the reverse of what you're talking about, but related) https://github.com/FusionAuth/fusionauth-issues/issues/1 (the very first issue filed!)

Please feel free to upvote them, as that helps direct our development efforts. If these issues don't cover what you're looking to do, please do file a feature request with use case specifics.

Thanks,
Dan

Looks like this might be an issue you'd want to upvote: https://github.com/FusionAuth/fusionauth-issues/issues/439

You can send us your jar file and we'll assist you. Just open a support ticket from your account page.

@dan

Hello,

I am happy that I got the answer for my doubt by going through the conversation.

thank you so much.

Samo

Great. Marking this solved. Let me know if that's not ok .

Ah, makes sense.

You should be able to export the email templates via the retrieve email template API and them re-import them using the same API. It may take a bit of fiddling, but it should be possible. In fact, you may want to capture the email templates as a kickstart file for future deployment/dev envt setup ease: https://fusionauth.io/docs/v1/tech/installation-guide/kickstart

I think we already have some issues about configuration migration, so you may want to check them out and vote for them if they convey what you'd like (please upvote them if so):

https://github.com/FusionAuth/fusionauth-issues/issues/576 https://github.com/FusionAuth/fusionauth-issues/issues/560

Hmmm. What version of FusionAuth are you running?

If you have set the refresh token usage policy to be OneTime in the tenant settings, then the old refresh token shouldn't give you access tokens after the first call.

Nope.

However, you can write some code to do this. You could write two scripts:

one to add a user, which should register them to all applications one to add an application, which should register all users

Further reading:

This post is probably worth a read, to clarify how FusionAuth handles users without an application registration: https://fusionauth.io/community/forum/topic/5/can-you-limit-a-user-s-login-authentication-access-to-applications-within-a-single-tenant/2?_=1597070984952

You also might be interested in voting up this issue: https://github.com/FusionAuth/fusionauth-issues/issues/772

You could also file a github issue explaining what you are trying to accomplish, perhaps there's a feature to be written to allow this.