WildFly - login page cannot access css files (FORM based authentication)

[marcos_aps]

Hello, everybody!

I'm trying WildFly. After I enabled FORM based authenticaton in my simple web application, the login page (or container) cannot access the css files located in the /resources/css directory. That is working in a JBoss 7.1 application that I have in production with the same configuration. This is the relevant configuration in my simple application using WildFly:

web.xml:

<security-constraint>
<web-resource-collection>
  <web-resource-name>restricted</web-resource-name>
  <url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
  <role-name>USUARIO</role-name>
</auth-constraint>
</security-constraint>

<security-constraint>
<web-resource-collection>
  <web-resource-name>allowed</web-resource-name>
  <url-pattern>/modelos/*</url-pattern>
  <url-pattern>/resources/*</url-pattern>
</web-resource-collection>
</security-constraint>

<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
  <form-login-page>/login.xhtml</form-login-page>
  <form-error-page>/errologin.xhtml</form-error-page>
</form-login-config>
</login-config>

  <security-role>
<role-name>USUARIO</role-name>
  </security-role>
  <security-role>
<role-name>NAO_AUTORIZADO</role-name>
  </security-role>

jboss-web.xml:

<?xml version="1.0" encoding="UTF-8"?>

<jboss-web>

    <security-domain>solicitacoes</security-domain>

</jboss-web>

standalone.xml:

<security-domain name="solicitacoes" cache-type="default">

    <authentication>

        <login-module code="br.urca.solicitacoes.visao.ModuloLogin" flag="required"/>

    </authentication>

</security-domain>

As you can see from the security configuration, the resources folder is unprotected, yet WildFly doesn't allow access to it before authentication. So, what am I missing or doing wrong?

Thank you.

Marcos

[marcos_aps]

After thinking about this issue, I think that I'm not doing anything wrong here. My configuration is ok, the same as other applications I have running on JBoss 7.1. Maybe this is just a bug in the web container for WildFly. I'm attaching my simple ear with the web application if you want to test for yourself.

I would appreciated a lot if someone helped me with this issue that doesn't let me proceed.

Thank you again.

Marcos

[sfcoy]

WildFly 8 has a brand new web container.

This looks like https://issues.jboss.org/browse/UNDERTOW-77.

[swd847]

This should be fixed in Wildfly Alpha2

[marcos_aps]

Stephen Coy wrote:

WildFly 8 has a brand new web container.

This looks like https://issues.jboss.org/browse/UNDERTOW-77.

Sorry for the delay in replying. I've just upgraded to Alpha2 and this issue is fixed there. That was indeed a problem in the web container. Thank you very much.

Marcos

PS.: This issue is not solved yet. See my next comment.

[marcos_aps]

Hey, I tought the issue was solved, but I tested a little more and there's still a problem. When I first start the jboss server the page is correctly rendered in the browser (the css files are accessed), but after I refresh the login page 5 times or more (using the browser refresh button), the page become unformatted again, this means that the css files are not being accessed anymore. I tested this using Firefox, Chrome and IE. So, after 5 refreshes the allowed resources are forbidden by the web container again.

Marcos

[sfcoy]

So, the CSS is protected, but the page content itself is not?

[marcos_aps]

Stephen Coy wrote:

So, the CSS is protected, but the page content itself is not?

Right, all the content is under the resources folder, including css and javascript files (/resources/css/*, /resources/script/*) is not accessed anymore after 5 page refreshes. The login page can still be accessed though.

Marcos

[marcos_aps]

It seems that the issue is even worse. I commented all the security section in the web.xml file (so I'm not using security or any form of authentication) and after five page refreshes the css and script files are not read anymore. If I want the files back I have to restart WildFly.

Marcos

[swd847]

Hmm, it looks like I managed to introduce a caching bug right before the release.

If you remove the

<buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>

element from standalone.xml it should start working again.

[swd847]

I have fixed this in undertow upstream.

[marcos_aps]

Stuart Douglas wrote:

Hmm, it looks like I managed to introduce a caching bug right before the release.

If you remove the

<buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>

element from standalone.xml it should start working again.

Have you tested this in a browser other than Firefox? In my computer it doesn't work on Chrome and IE, only in Firefox.

Marcos

[piotr.kucia]

swd847 - Could You confirm that it is solved in WildFly 8.1.0.Final?

I'm facing this issue in WildFly 8.1.0.Final and I'm looking for any solution or a workaround..

I can give you more details on my installation if necessary.

btw. removing <buffer-cache name="default">  from undertow subsystem configuration in standalone.xml causes that server won't start.

Any help will be appreciated

EDIT:

As I written in [UNDERTOW-77], my problem was related to lack of leading "/" sign in url-pattern of unsecured constraint. I'm not sure whether it is a bug or not, but solution is simple

[sakthiprabhu]

Hi,

I too faced the same issue as stated.

Problem stated by Piotr can also be handled using a RE  to restrict the URL patterns.

<security-constraint>

        <web-resource-collection>

            <web-resource-name>Secured Core Context</web-resource-name>

            <url-pattern>/unauthenticatedRequest/*</url-pattern>

        </web-resource-collection>

  </security-constraint>

<security-constraint>

        <web-resource-collection>

            <web-resource-name>Secured Core Context</web-resource-name>

            <url-pattern>*.action</url-pattern>

        </web-resource-collection>

        <auth-constraint>

            <role-name>*</role-name>

        </auth-constraint>

  </security-constraint>

Here every *.actions should be authenticated by roles unless it is in the path /unauthenticatedRequest.

This can be achieved using Regular Expressions :

<security-constraint>

        <web-resource-collection>

            <web-resource-name>Secured Core Context</web-resource-name>

            <url-pattern>/unauthenticatedRequest/*</url-pattern>

        </web-resource-collection>

  </security-constraint>

<security-constraint>

        <web-resource-collection>

            <web-resource-name>Secured Core Context</web-resource-name>

            <url-pattern>^((?!/unauthenticatedRequest/)*.)*.action</url-pattern>

        </web-resource-collection>

        <auth-constraint>

            <role-name>*</role-name>

        </auth-constraint>

  </security-constraint>