Trying to migrate to a new server with the current database and the same codebase

Feature(s) impacted

setting up a new project or a new environment in the current project

Observed behavior

When setting up a new project, deploying to production after setting up locally causes an “Unable to authenticate you” popup. The get request goes to the localhost:3310 and not to the remote server I defined in the Admin backend URL field.

Trying instead to create a new environment on my current project, results in getting redirected to the project selection page with a “Project not found” error

Expected behavior

Creating a new project and deploying to production should direct the get requests for authentication to the server url I defined in the Admin backend URL field for the production environment.

Deploying a new environment in my current project should deploy the project and not kick me out of the project with a project not found error

Failure Logs


New environment on current project:

  • Project name: GSL_Admin
  • Team name: Developers
  • Environment name: TEST23

new project:

Hi @ofgsl and welcome in our community,

I’m going to check your project to see if I can find the issue. Let me a few minutes :male_detective:

Everything seems correct :thinking:. DO you still experiment this issue ?

I’m new to forest admin and facing same issue. Why the authentication call back calls to localhost:3310? I’m tried to change my application url. But it’s still call the localhost:3310.

Hello @ofgsl,

We are experiencing cache refresh issue on certain actions, I have manually refreshed your cache. Could you please tell me if you still encounter any issue on your environments ?

Best regards,

Hello @Sawfish_Developers and welcome to our community !

I’m sorry to hear that you have issues with your configuration.
For us to be able to help we will need more details as it appears to me you are not facing an issue with cache refreshing.

Could you please open a new topic with the template filled out ? Thanks

Best regards,

No, the problem with the authentication going through the local host still persists

From what I can see, the configuration of your environment points to an url different from localhost:3310, and you should have no issue with cache refreshing.
Can you please simply refresh your frontend ?

I did have an instance where it tried to authenticate with the server after refreshing, but then it reverted back to the localhost

The behaviour of “reverting” to the older url was due to bad cache refreshing, you should no longer experience a similar issue. We’re sorry for the inconvenience.

Best regards,

I emptied the cache on my end and I still get the localhost authentication issue

I was looking at your Production environment from GSL_Admin_2023, if you’re experiencing this issue on environment test_23 from GSL_Admin, it appears that your agent hasn’t reached our backend yet. Is the agent running ? Can it reach ? Do you have any error log from your agent when running it ?

when trying to connect with the test_23 from GSL_Admin env_secret, it hangs on waiting for your backend to run. when trying with the GSL_Admin_2023 Production env_secret, it tries to authenticate through the localhost and through the server

the test_23 from GSL_Admin, tries to authenticate through the server url on the Production environment and not through the new one I am trying to migrate to and defined in the Admin backend URL field

It appears to me that both your test_23 and Production environments point to the same backend URL, can you try to update the apiEndpoint of your test_23 environment once more ?

They are pointing to the same URL because that is the new server I am trying to migrate to

I changed the url to other locations and it works, it sends the request to those locations but when I change it back to my server url, it reverts back to localhost

When you refresh your page with your web console open, can you give me the result of this call in the network tab ?

[Picture deleted]
This is the response

This is the OPTION call, I need the GET one. Ad just send the response (without the query parameters :pray: )