Results 1 to 10 of 12

Thread: AuthRequest not creating/returning session on most calls ???

Hybrid View

  1. #1
    Join Date
    Oct 2009
    Location
    Dublin, IRELAND
    Posts
    712
    Rep Power
    7

    Default [SOLVED] AuthRequest through NGINX proxy not creating/returning session on most calls

    I am troubleshooting an issue with a user of the z-push zimbra backend, and it has come down to the fact that for some reason when the AuthRequest is passed to the backend, it is not opening a session every time, and as a result is not passing back the session refresh block, and cannot initiate a WaitSet.

    A random section of the debug log shows that maybe one in every 4 AuthRequest calls is getting a session. The others are just returning a token but with no session context created.

    Has anyone any idea what would prevent/limit zimbra from opening a session ?

    The configuration is one zimbra proxy in front of 3 or 4 mailstores. They are running 7.2.0 FOSS
    Last edited by liverpoolfcfan; 10-16-2013 at 04:53 AM. Reason: marking solved, adding NGINX to title

  2. #2
    Join Date
    Jul 2010
    Posts
    113
    Rep Power
    5

    Default

    One case that comes immediately to mind is that AuthRequest will not create a session for mailboxes which reside on a different host. Since you are accessing the mailstores through a proxy you may need to send an additional request (perhaps NoOpRequest) after AuthRequest to get a sessionId.

  3. #3
    Join Date
    Oct 2009
    Location
    Dublin, IRELAND
    Posts
    712
    Rep Power
    7

    Default

    Thanks for the pointer.

    How would I know that I have hit a proxy ?

    The documentation states that I should get back a <refer> tag always - yet I never see one in the response.

    Why would some AuthRequests work and others not for the same account connecting to the same hostname ?

  4. #4
    Join Date
    Jul 2010
    Posts
    113
    Rep Power
    5

    Default

    You mentioned in the original post that you are using a proxy. I am not familiar with this 3rd party 'zpush' you are using; but I assume it uses a single URL to connect to the mailstore servers. Therefore, I assume it is using the reverse proxy (nginx) URL so it can access any mailbox. You can know for sure by understanding the hostname of each server.

    The behavior of the <refer> tag is controlled by the zimbraMailReferMode LDAP attribute. It sounds like this is set to reverse-proxied which means refer will never appear. If you see misleading documentation somewhere please file a bug against the 'tech docs' component so we can get it updated. Here's the actual description from zimbra-attrs.xml:

    whether to send back a refer tag in an auth response to force a client redirect.
    always - always send refer
    wronghost - send refer if only if the account being authenticated does not live on this mail host
    reverse-proxied - reverse proxy is in place and should never send refer

    As for why AuthRequest may return different results for the same account; again I'm assuming you are connecting through the proxy. The initial AuthRequest is routed from the proxy to any of the available mailstore servers using round robin and IP hashing algorithms. Depending on which mailstore the request lands a session may or may not be created.

    Hope this helps. If you want to understand more you may want to take a look at the HTTP access logs on the proxy and mailstores.

  5. #5
    Join Date
    Oct 2009
    Location
    Dublin, IRELAND
    Posts
    712
    Rep Power
    7

    Default

    Z-Push is an opensource ActiveSync implementation. The zimbra backend connects, normally to zimbraPublicURL appended to '/service/soap/', to send soap requests to the server. The system is working great against version 5,6,7 & 8 single node servers. But, it seems that when the proxy is in front a session is not getting created all the time - so the phone keeps seeing folders appear, then disappear, then appear again, then disappear again, and so on ...

    OK - I understand the the refer tag appearing or not. That is clear. Thank you.
    Quote Originally Posted by jflanigan View Post
    As for why AuthRequest may return different results for the same account; again I'm assuming you are connecting through the proxy. The initial AuthRequest is routed from the proxy to any of the available mailstore servers using round robin and IP hashing algorithms. Depending on which mailstore the request lands a session may or may not be created.
    This makes sense then. If it happens to get routed to the actual mailstore that hosts the account it gets a session opened. That case is good.

    But in the case I don't hit the right server first time, how do I get connected to the right one ? I have tried issuing a NoOpRequest, and it does not start a session.

    Is there a pref or an attr I should look for that would direct me to structure a header differently ? Or anything else I need to do differently to handle this situation ?
    Last edited by liverpoolfcfan; 10-15-2013 at 02:06 PM.

  6. #6
    Join Date
    Jul 2010
    Posts
    113
    Rep Power
    5

    Default

    You can request a new session by specifying <session/> in the SOAP header.

    <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
    <soap:Header>
    <context xmlns="urn:zimbra">
    <authToken>...</authToken>
    <session/>
    </context>
    </soap:Header>
    <soap:Body>
    <NoOpRequest xmlns="urn:zimbraMail"/>
    </soap:Body>
    </soap:Envelope>

Similar Threads

  1. session id does not returned in AuthRequest
    By koudounias in forum Developers
    Replies: 0
    Last Post: 06-18-2013, 06:09 AM
  2. Replies: 3
    Last Post: 05-09-2010, 09:10 AM
  3. Problema con el authRequest
    By ldcl289 in forum Spanish
    Replies: 0
    Last Post: 04-20-2010, 04:28 PM
  4. SOAP AuthRequest Question
    By ab5602 in forum Developers
    Replies: 3
    Last Post: 08-06-2008, 09:55 PM
  5. Replies: 0
    Last Post: 10-01-2007, 03:14 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •