Ignition 7.2.10 - Console error 302 Login Failed

Has anyone had this error crop up in the console?

com.inductiveautomation.ignition.gateway.servlets.Gateway ERROR(302): Login Failed.

I had converted a couple of old FactoryPMI projects to Ignition 7.2.10 and everything was running smooth this morning but around 3pm this afternoon I noticed I started getting this error showing up in the console. The gateway service had restarted on it’s own but this error still occurs.

If anyone can lend some of their wisdom it would be greatly appreciated.

That error would indicate that a client is attempting to log in, but failing. Your post is written is such a way that it seems to me you’re not aware of any failed login attempts, so the first thing to do would be to track down who’s trying to log in, and make sure that it’s expected, and that they’re confident that the password should work.

Once you’ve confirmed that it’s not just someone trying to guess passwords, the next step would be to look at how your authentication profiles are set up. If you’re using DB based authentication, it could indicate that your DB connection is down. Or, perhaps somehow the authentication profile settings for the project got modified somehow. Log into the gateway, and check:

  1. What kind of authentication profiles are set up
  2. Which profile your project(s) is/are set to use
  3. If the profiles seem to be working ok (db connections up, no other errors in console).

If something is really wrong and you can’t log into the gateway, you can reset the root password using the GCU (launched from the start menu).

Hope this helps,

Hey Colby,

It could be a possibility that someone is loging in but I’m the only one that knows that this project exists in Ignition. The strange thing is this error is coming in every minute or so continuously. All the database connections are showing a green checkmark saying valid connection. and there is nothing piling up in the Store and Forward buffers.

Is there a way to get more detailed console entries?

are you using active directory/db hybrid?

Yes we are, have you seen something similar happen?

yes, I had a similar issue using 7.2.11. one of the AD users repeatedly had failed login attempts being logged once every minute or two. I thought someone had hacked his machine and was trying to get into the system. we looked at traffic between Ignition and the AD server and didnt see anything unusual. after about 12 hours it stopped on its own and I havent noticed it do it again.

Interesting… unfortunately for me it’s been doing this since this past Friday at around 3pm. I don’t have any clients logged into ignition and I’ve restarted the gateway service manually in addition to the restart that occurred on Friday on it’s own.

There are two issues that appear to be happening, one is that the log files are growing faster than they normally did and the seconds one is that I’m not able to export my projects from the gateway right now. I have backups of the projects as of Friday morning but a little unsettling knowing that I can’t take backups right now.

I’ve done a little more digging and turned on the more detailed logging to find the following entries:

9:39:54 AM Gateway No session found for authenticated gateway call: 80
9:39:54 AM Gateway No session found for authenticated gateway call: Alert
9:39:54 AM Gateway No session found for authenticated gateway call: SQLTags
9:39:53 AM Gateway No session found for authenticated gateway call: RunQuery

Perhaps a server reboot would fix this problem?

I’m fairly certain that this is caused by a client that is running out there that is currently in the “Attempting to re-connect to Gateway” mode.

You won’t see this client on the sessions list because it doesn’t have a session. Each time it tries to reconnect it attempts to re-authenticate, but apparently the user/password combination it has is no longer valid.

Unfortunately, restarting the gateway won’t help (the client will still be out there, somewhere…)

You might be able to use netstat or wireshark to see where incoming traffic is originating from on the gateway’s HTTP port. Or you could change the port to a different port so that this client couldn’t connect at all. Or you could find the client and shut it down :slight_smile:

Carl, I have been looking in the gateway log file and have been able to cross reference with threads:

http-8088-2

Stackjava.net.SocketInputStream.socketRead0(Native Method)java.net.SocketInputStream.read(Unknown Source)org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:730)org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:366)org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:806)org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)java.lang.Thread.run(Unknown Source)

http-8088-3

LockingWaiting for org.apache.tomcat.util.net.JIoEndpoint$Worker@e6449cStackjava.lang.Object.wait(Native Method)java.lang.Object.wait(Object.java:485)org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:416)org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:442)java.lang.Thread.run(Unknown Source)

http-8088-4

Stackjava.net.SocketInputStream.socketRead0(Native Method)java.net.SocketInputStream.read(Unknown Source)org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:730)org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:366)org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:806)org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)java.lang.Thread.run(Unknown Source)

Not too sure if these help at all? I’m still looking into the netstat route.

Unfortunately those thread stacks don’t tell me much of anything.

Is it possible to log the IP address of a failed login attempt?

Carl thanks for your help, I was able to use wireshark and find out the two users whose logins were failing. Everything has now cleared up.

Glad it’s resolved. As of 7.5, the audit log will include the IP of the failed login attempt, and they won’t appear in the system log anymore.