You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Then I connect to APISIX node 2, and use the ticket to authenticate Websocket:
ws://apisix.example.com:9080/jmap/ws?ticket=b11279c9-ac0c-4515-93a2-7d25deefe414
=> 401 Unauthorized, with TMail log org.apache.james.jmap.exceptions.UnauthorizedException: User is forbidden to use this ticket.
Reason: we enforce IP checking for ticket! Therefore the ticket is stateful.
The same would happen with MU deployment.
This is a technical limitation IMO and we should revise it.
The text was updated successfully, but these errors were encountered:
Ok the issue comes from the source IP not to be preserved through the load balancing process.
We likely need a X-Real-IP header (or something like this) to be positioned on requests by the load balancers. APISIX should likely keep those header unchanged ( as it is itself load balanced ) and James should base its decisions based on the real-ip if supplied, falling back to the ip address of the socket if none.
We of course shall check the the outward most load balancer can not be tricked by the clients by supplying X-Real-Ip.
(It is a very good occasion to work on real IP preservation for HTTP based protocols, the way we did with PROXY protocol.)
Today ticket (for Websocket web authentication) is IP bound.
If I have 2 APISIX nodes (what we have with CNB): node 1 with IP
172.19.0.1
and node 2 with IP172.19.0.2
.I get the ticket via node 1:
POST http://apisix.example.com:9080/jmap/ws/ticket
Then I connect to APISIX node 2, and use the ticket to authenticate Websocket:
ws://apisix.example.com:9080/jmap/ws?ticket=b11279c9-ac0c-4515-93a2-7d25deefe414
=> 401 Unauthorized, with TMail log
org.apache.james.jmap.exceptions.UnauthorizedException: User is forbidden to use this ticket
.Reason: we enforce IP checking for ticket! Therefore the ticket is stateful.
The same would happen with MU deployment.
This is a technical limitation IMO and we should revise it.
The text was updated successfully, but these errors were encountered: