Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 1620 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

We upgraded to FMS19 today and Google OAuth no longer works. The select an account screen comes up in a Browser, the redirect to our server is called and then there is no error and the DB is not logged in. It just leaves you at the login window. You could repeat this process over and over.  If you reload the redirect URL you get an Authentication Failed error which I what I would expect if the authentication was failing. I think the original auth request is successful but does not open the DB.

I also tested on another server with the same results.

 

Posted

I've been using FMS19 extensively with OpenID Connect OAuth providers so I know the underlying mechanism works.

I would suggest using https://oidcdebugger.com/ to initiate an auth request and complete the second step with Postman so that you have a chance to inspect the id_token that you get back.

You'll need to add https://oidcdebugger.com/debug to your list of Redirect URLs on the Google side.

19 minutes ago, RyanB said:

It just leaves you at the login window

Which one?  The FM one or the Google one?

If you changed the DNS name of your server, make sure to update the redirect URLs on the Google side.

Posted

I was referring to the FM Login Window. No DNS names have changed. I will check out oidcdebugger. That might be just what I need. Thanks

Posted

I thought that too and checked our firewall. Nothing should be getting blocked so I am not sure why it is stopped.

Is FMS 19 using any new ports?

I have never used https://oidcdebugger.com/

I am not sure what to put for Authorize URI (required), Response type (required) , or Response mode (required)

 

Posted

Check out addendum 4 of our series of white papers:

image.png.1293f4f57de25ec45bade1095dddbd25.png

It describes how to use oidcdebugger and postman to simulate the whole process and to inspect the id_token.

And no: no different ports because this all goes on port https (443), none of it is FMS-specific.

Posted

Thanks. I have not worked through the document yet but I have discovered a possible cause. We use internal DNS in our office which points traffic to our FM Server FQDN to the LAN IP.

Oauth is working fine outside the Office and if I edit my host record to resolve to the FMServer using the public IP Oauth works fine. This all worked before the upgrade. It makes no sense because DNS resolves fine internally and externally.

Posted

Yes, would be weird.  The only thing I can think of are the SSL issues with Comodo that started around June 1st, if your FMS SSL cert was affected by the expiry of the intermediate bundle from Sectigo then perhaps that is what is in play and the FMS19 upgrade is a red herring?

This topic is 1620 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.