Sorry to be late... I was on holidays :-) Le 24/10/2014 00:20, Ryan Kelly a écrit :
Before testing without any layer of proxying, I've done some tuning into my first layer or reverse proxy : proxyPreserveHost OnOn 23/10/2014 7:58 PM, Philippe MARASSE wrote:[Thu Oct 23 10:27:08 2014] [error] INFO:mozsvc.metrics:{"tokenserver.backend.get_user": 0.002335071563720703, "code": 200, "request_time": 0.21599602699279785, "remoteAddressChain": ["192.168.3.14", "192.168.10.168"], "agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0", "tokenserver.assertion.verify": 0.21174216270446777, "token.assertion.verify_success": 1, "path": "http://ff-sync.domain.local/sync/token/1.0/sync/1.5";, "method": "GET"}This appears to be a successful verification via the proxy, which is good. Your env adjustment must have done the trick.Actually, the way from FF to sync server is : FF => Apache reverse proxy (+mod_security) 192.168.10.168 => Apache on sync server (192.168.10.81) => python sync server via mod_wsgiI'd suggest you try removing components from this stack and see if you can make it work in a simpler setup. E.g. try disabling mod_security, disabling the two levels of proxying, etc.the path in error log shows up http://ff-sync.domain.local/sync/token/1.0/sync/1.5 which is not related to public_url.Ah, so if the app thinks its URL is something other than what's configured in public_url, things are likely to break. Because of the way we use request-signing for auth, both Firefox and the server have to agree on the publicly-visible hostname of the app. That's probably what's causing this 401 on the sync storage request:192.168.10.168 - - [23/Oct/2014:10:27:07 +0200] "GET /sync/storage/1.5/1/info/collections HTTP/1.1" 401 303 "-" "Firefox/33.0 FxSync/1.35.0.20141011015303.desktop"To guess, I'd say that the double-layer of apache proxying means the app is not getting e.g. the correct Host header, SSL-indicator headers, or something like that. If you pull the latest git master of syncserver, it should have some new debugging/error output to tell you exactly what the mismatch between public_url and the app's view of itself might be.
Without success but an interesting thing found in error.log :[Fri Nov 07 15:12:57 2014] [error] ERROR:syncserver:The public_url setting does not match the application url. [Fri Nov 07 15:12:57 2014] [error] This will almost certainly cause authentication failures! [Fri Nov 07 15:12:57 2014] [error] public_url setting is: https://service.domain.public/sync [Fri Nov 07 15:12:57 2014] [error] application url is: http://service.domain.public/sync
[Fri Nov 07 15:12:57 2014] [error]Request path is : Client => service.domain.public/sync (https) => ff-sync.domain.local (http) => mod_wsgi.
So sync server is not aware of SSL after the first layer of reverse proxy... Since I don't know how to fool the second layer of apache proxy or mod_wsgi, I've added HTTPS on this server and now it seems to work as expected :-)
The new path is : Client => service.domain.public/sync (https) => ff-sync.domain.local (https) => mod_wsgi.
Sync server seems to be happy now :-) (an so I am). Thank you. Cheers. Philippe. -- Philippe MARASSE Responsable pôle Infrastructures - DSIO Centre Hospitalier Henri Laborit CS 10587 - 370 avenue Jacques Coeur 86021 Poitiers Cedex Tel : 05.49.44.57.19
smime.p7s
Description: Signature cryptographique S/MIME
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
