Error 400 Bad Request

Every time I try to launch my project using the IDP authentication strategy, I’m able to type my username and password but after I log in I get this:

HTTP ERROR 400 Bad Request

URI: /data/feerate/callback/ignition
STATUS: 400
MESSAGE: Bad Request
SERVLET: DataRoutes

http://localhost:8088/data/federate/callback/ignition?code=Pe9jeyli8HfR49NJuGk-Wn5aMjrTj_ZhCDVmGDHBV8M&state=-CR-5VmRh_O0K2BdR5ppYcUa1ameWsoMbS_XjNfT_Qs

In which version of Ignition are you running into this issue?

What part of Ignition are you logging into? (i.e. Perspective? Gateway Web Interface? Designer? Vision client?)

What kind of device are you on? (i.e. Perspective Mobile App on iOS/Android, Perspective Workstation, web browser such as chrome / safari / FF on windows?)

Do you have a setup involving multiple Gateways behind a load balancer?

  1. Version 8.1.0
  2. Designer
  3. Web browser (Chrome)
  4. I don’t think so.

if you set gateway logger gateway.FederationRoutes to debug level, and trigger the failed login error again, do you see any messages in the gateway logger?

I see this message now:

FederationRoutes 16Feb2021 16:09:54 Unable to parse the error redirect URI from the relay state JWT

I’m using an ignition IDP

Are you sitting on the login page for a while? I think you only have about 2 minutes from the time you trigger the login in the designer to the time you complete the login before the login request times out.

I’m also wondering if there are some browser cookie issues at play here. Did you recently access the Gateway in your web browser using https:// (SSL/TLS)? If so, and if force secure redirect is not enabled in Gateway Web Interface > Config > Networking > Web Server, and if you are trying to login to the designer over insecure http://, I could see how your web browser might refuse to honor cookies on the insecure connection. Perhaps try clearing the cookies for the hostname(s) or IP(s) the Gateway is running on from your web browser and try again. Or use one protocol (preferably secure https://) in all your interactions with the Gateway…

No, I’m logging in as soon as I launch the project.

I tried clearing the cookies for the hostnames the Gateway is running on from my web browser. I also tried accessing the gateway with both https:// and http:// and I still get the same error. This error happens regardless of the browser I use, either Chrome or Firefox

v8.1.27

I'm seeing a slightly, similar problem. I have several Raspberry Pis running Perspective in Chromium in full screen mode (v74.0.3729.157). I was never able to get workstation working on a RPi.

I'm authenticating with an Ignition IdP which opens up to authenticate (badge) right after the browser is launched on reboot/startup. If the gateway disconnects for some reason and comes back up, the browser has to be closed and relaunched for the idp to start working again.

The badge login screen is still up, but any scan just says bad login information or something like that. If you press the exit login button I get the following error.

HTTP ERROR 400 Bad Request

URI: /data/federate/callback/ignition
STATUS: 400
MESSAGE: Bad Request  

If the session is authenticated during the disconnect, it redirects to the idp and logs back in without issue. It's only when the project is unauthenticated during the disconnection that renders it useless once the gateway comes back up.

With the stations not having keyboards makes it hard to restart the sessions without rebooting all the computers.

Did anyone ever resolve this? I've got one specific user out of dozens who is receiving this same error message and, on turning on the logging, I'm getting the same logged text about the redirect URI. Like the user here, he insists he is not waiting to log in. I haven't yet heard from him to see whether changing browsers helps.

Okay, not sure why this worked, but it did: A second user got the same error, but then discovered that when he browsed to the site without using his bookmark, it worked. The first user was using a bookmark, too, and on trying without one he could get in, too.

So in our case, there was something odd going on with the browser bookmarks. Hope this helps someone . . . .