0

We are running an AngularJS application on JBoss WildFly. It used to work fine on both, our testing environment and in production. How, however, there is a weird error 403 issue in production now.

Users can load data by REST request. On one site, a cookie is set to store a filter option. Once the cookie is set, all subsequent requests fail and an error 403 (Forbidden) is shown.

Locally and on our remote test server this issue does not exist. In production it used to work, too, but something must have changed. It happens in all browsers and for all users, so I assume, that our IT department must have changed the server configuration. However, I cannot figure out the root cause of the problem.

The server responds with the following headers:

Server: Apache
X-Powered-By: Undertow/1

But I know that we are running JBoss WildFly. There are no useful entries in neither the JBoss log nor the browser's developer console. I do not manage the server infrastructure, but I need to solve this issue urgently.

My questions are:

  1. Where does JBoss log requests to the web server? Is there an additional access log file (/var/log/apache2/error.log does not exist)?

  2. Why does the header claim that the server is Apache? The standalone.xml file of JBoss sets "WildFly/9". Is there another server handling requests in between? How can I find out?

  3. Do JBoss or Apache log the cause of such errors at all? Do I have to increase log levels?

Once I delete the cookie, the site is back to normal. I'm sure it is just a small configuration issue, since it has worked before, but I cannot figure it out right now. Any hints are greatly appreciated.

user1438038
  • 171
  • 2
  • 9
  • Good write-up on 403 topic, didn't help me, however. But might be useful for other users that came here with similar issues: https://airbrake.io/blog/http-errors/403-forbidden-error – user1438038 Jan 24 '20 at 12:03

1 Answers1

2

Add this block to standalone.xml in subsystem urn:jboss:domain:logging:3.0:

<logger category="org.jboss.security">
  <level name="TRACE"/>
</logger>

Restart server, so it picks up the new configuration.

Now perform interactions to cause error 403. More detailed information will be logged to server.log file now. This helped me to get details about the root cause of the problem at least. Seems like mapping roles from Active Directory fails. Still have to investigate further, though.

But at least increasing the log level, as described above, helped me debugging.

user1438038
  • 171
  • 2
  • 9