Hiya @maciej-wisniowski

Might make sense to file a feature request. I am not sure how likely we'd be to expose the SSO token to revocation, but we already (I believe) display it in the list of refresh tokens for a user (with an API key).

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

I can't think of many workarounds simply because there are two disjoint users (as FusionAuth sees them, because they have different login Ids) and yet you are trying to connect them (so the same human person doesn't login with two different accounts).

Hmmm. I saw a similar issue and filed a bug: https://github.com/FusionAuth/fusionauth-issues/issues/1466

Feel free to file a bug with reproducible steps in the issues repository or add comments to #1466 if you have any more info.

@richb201,

I assume you are self-hosting FusionAuth, but let me know if this is not the case.

I had to split the server into two different copies. One at researchstudyonline.com and one at staging.researchstudyonline.com.

The database is the source of state in FusionAuth. So if you copied the database, then the same users and their logins should exist in that new copy. For how you have set up FusionAuth, I would expect your staging environment would have its own database as well as production.

When I click on http://staging.researchstudynline.com/ I see that the link is broken. You may want to review your configuration and ensure that you have properly set up the new FusionAuth instance (http://staging.researchstudynline.com:9011/) and its associated database.

I am linking the appropriate documentation which may aid you further in installing a new FusionAuth instance and database:

https://fusionauth.io/docs/v1/tech/installation-guide/ https://fusionauth.io/docs/v1/tech/installation-guide/common-configuration/ https://fusionauth.io/docs/v1/tech/reference/configuration/

Lastly, there are a few different ways that you could replicate a database. One such way would be to use the pg_dump command. Once you have your dumped database, create a new empty database, and use pg_restore to import your data. Once you have your new database, you would stand up a new FusionAuth instance and point that instance at this new datastore. I would encourage you to use your search-fu to find articles that will speak to how to complete a database replication if you have any other questions about this process.

Hope this helps!

Thanks,
Josh

Thanks @joshua !

Perfect Joshua.

This gives me what I need!

Thank you!

Thanks. I set up two databases now instead of just one and having both production and staging share it. But I find when I go into the FA control panel on staging and change things such as paths it changes the paths for both the staging and the production servers.

Where do I specify (for each server) what database should be used?

@anthonysavoji88

I don't know if I follow the issue that you are experiencing? Can you elaborate?

They’re uploading there statements and paystubs and the server is denying the pdf .

This sounds like business logic / integratino code. FusionAuth is an Auth solution and does not directly speak to uploading pdfs. Perhaps this is related to the workflow that you are trying to use and FusionAuth plays a role in authorization?

Thanks,
Josh
FusionAuth

@sharma Unable to connect to your database using either the superuser username and password or ordinary username and password you provided. Please verify your connection information. If it is correct, make sure the database is running before continuing.