Wildfly returning 403 on second SPA request

[space.bo...@gmail.com]

Hello

We have an ear containing our backend application in a war and the front end one, a SPA, in another war. Session sharing is enabled. We are on WD 18.0.1.

When we login and do multiple queries on the backend manually in the browser all works fine.

However when the SPA fires its second REST request, a 403 Forbidden is returned by Wildfly:

- the query doesn't arrive at the backend application

- the query has the correct JSESSIONID cookie

- running with plenty of server logs doesn't show anything strange (root logger set to TRACE and having removed irrelevant logs)

Feels like i'm missing something obvious, any idea of what?

Thanks in advance

best regards,

[Jose Socola]

Can you share your standalone.xml <server-host>....  Do you check access_log if the request was accepted?

Regards,

JS

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/976f9a84-1858-4b51-ac41-ac68c6fd3635n%40googlegroups.com.

[Jose Socola]

If you try with curl the request is completed?

curl --header 'Set-Cookie: JSESSIONID=XXXXX' https://server/myrest/v?q=values&...

Regards,

JS

[Jose Socola]

curl --cookie 'JSESSIONID=' https://server/myrest/v?q=values

[space.bo...@gmail.com]

Looks like my previous reply was lost

So back to it:

Thanks a lot for your reply!

Regarding your questions:

- requesting the backend through an url in the browser or with postman (providing the jsessionid) both work

- all requests are present in the access log, they fail later

- my initial standalone for this bit was :

        <subsystem xmlns="urn:jboss:domain:undertow:10.0" statistics-enabled="true">
            <buffer-cache name="default"/>
            <server name="default-server">
                <http-listener name="default" socket-binding="http" max-parameters="5000" allow-unescaped-characters-in-url="true"/>
                <host name="default-host" alias="localhost">
                    <access-log pattern="%h %t &quot;%r&quot; %s &quot;%{i,User-Agent}&quot;" use-server-log="false"/>
                    <filter-ref name="x-frame-options"/>
                </host>
            </server>
            <servlet-container name="default" default-encoding="UTF-8" max-sessions="10000">
                <jsp-config/>
                <session-cookie http-only="true"/>
            </servlet-container>
            <filters>
                <response-header name="x-frame-options" header-name="X-Frame-Options" header-value="SAMEORIGIN"/>
            </filters>
        </subsystem>    

i tried this but it didn't help:

        <subsystem xmlns="urn:jboss:domain:undertow:10.0" statistics-enabled="true">
            <buffer-cache name="default"/>
            <server name="default-server">
                <http-listener name="default" socket-binding="http" max-parameters="5000" allow-unescaped-characters-in-url="true"/>
                <host name="default-host" alias="localhost">
                    <access-log pattern="%h %t &quot;%r&quot; %s &quot;%{i,User-Agent}&quot;" use-server-log="false"/>
                    <filter-ref name="x-frame-options"/>
                    <filter-ref name="limit-connections"/>
                </host>
            </server>
            <servlet-container name="default" default-encoding="UTF-8" max-sessions="10000">
                <jsp-config/>
                <session-cookie http-only="true"/>
            </servlet-container>
            <filters>
                <request-limit name="limit-connections" max-concurrent-requests="3000" queue-size="100"/>
                <response-header name="x-frame-options" header-name="X-Frame-Options" header-value="SAMEORIGIN"/>
            </filters>
        </subsystem>    

While testing/trying further, they were occasions where all the requests to the backend, from the SPA, succeeded, about 1 in 10 i would say. I see nothing in the server.log or the application log (which i put all to trace and cleaned up after to remove the lines i didn't care of).

[space.bo...@gmail.com]

also i get less 403 often when i'm  running in debug (through intellij)... Something being too fast somewhere??

[space.bo...@gmail.com]

well, we serialized the SPA app calls to the backend and then... it works!

Turn out Wildfly can handle only one request per session at a time https://stackoverflow.com/questions/59628633/why-cant-the-wildfly-server-handle-concurrent-rest-requests-after-a-httpsession

Now we're digging into how to configure it correctly... no so clear/easy.

[Jose Socola]

I think the message the code for concurrent is 503 instance of 403 is handler

I don't see your code but i will put a little thinks so you can try or check if you have that

asyncSupported = true

You can change max concurrent here,

[standalone@localhost:9999 /] /subsystem=web/connector=http:write-attribute(name=max-connections,value=100)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

Maybe response don't return session and is broken check this

https://stackoverflow.com/questions/2138245/session-is-lost-and-created-as-new-in-every-servlet-request

Regards,

JS

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/48285db1-b45e-407d-8c38-b5e10a0cd7ffn%40googlegroups.com.

[space.bo...@gmail.com]

Thanks a lot again JS!

Which kind of handler is 403? I'm trying to debug this matter...

Regarding the access log, in there i see lines like these

127.0.0.1 [02/Jul/2020:22:54:46 +0200] "GET /api/Foo?bar=1 HTTP/1.1" 403 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36"

So one can see the 403

For asyncSupported, looks like it's more related to websockets. Furthermore it's a spring boot deployed in Wildfly (with SpringBootServletInitializer): when doing java -jar mywar.war it works fine (concurrent requests are ok). I don't see what to put where regarding async.

For max concurrent, i did it and now in my standalone.xml it's

                <http-listener name="default" max-connections="100" socket-binding="http" max-parameters="5000" allow-unescaped-characters-in-url="true"/>

I also tried it when adding the following  limit-connections filter, without success:

            <server name="default-server">
                <http-listener name="default" max-connections="100" socket-binding="http" max-parameters="5000" allow-unescaped-characters-in-url="true"/>

                <host name="default-host" alias="localhost">
                    <access-log pattern="%h %t &quot;%r&quot; %s &quot;%{i,User-Agent}&quot;" use-server-log="false"/>
                    <filter-ref name="x-frame-options"/>
                                        <filter-ref name="limit-connections"/>
                </host>
            </server>

            <filters>
                <response-header name="x-frame-options" header-name="X-Frame-Options" header-value="SAMEORIGIN"/>

                <request-limit name="limit-connections" max-concurrent-requests="3000" queue-size="100"/>

             </filters>

In the end i've the feeling undertow isn't properly set up, do you concur?

thanks again!

[space.bo...@gmail.com]

Problem solved: the front app, in a war in the ear, wasn't in a security domain. And the default security domain isn't the one used by the other wars.

We have put the front war it in the same domain (through the jboss-web.xml) and ... no more 403! We're a bit surprised the 403 wasn't on each call but then we're glad it works.

Thanks again!

[Jose Socola]

Good Job!

Regards,

JS

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/9d281077-a524-4138-b6a7-a6fab90700cfn%40googlegroups.com.