Results 1 to 3 of 3

Thread: Soap request header attribute

  1. #1
    parin is offline Active Member
    Join Date
    Feb 2013
    Location
    India
    Posts
    28
    Rep Power
    2

    Default Soap request header attribute

    Hi,

    can anyone explain me the usage of soap header child named <authTokenControl> and <change> under <context> element. the standard structure for any soap request found in soap.txt.

    <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
    <soap:Header>
    <context xmlns="urn:zimbra">
    [<authToken>...</authToken>]
    [<authTokenControl voidOnExpired="1"/>]
    [<session [id="{returned-from-server-in-last-response}" [seq="{highest_notification_received}"] [type="admin"]/>]
    [<account by="name|id">{account-name-or-id}</account>]
    [<change token="{change-id}" [type="mod|new"]/>]
    [<targetServer>{proxy-target-server-id}</targetServer>]
    [<userAgent name="{client-name}" [version="{client-version}"]/>]
    [<via>{request-ip(user-agent)[,...]}</via>
    [<format type="{response-format}" />]
    </context>
    </soap:Header>
    <soap:B"ody>
    <FooRequest ... [requestId="{client-generated-id}"]>
    </FooRequest>
    </soap:Body>
    </soap:Envelope>

  2. #2
    gren is offline Zimbra Employee
    Join Date
    Aug 2010
    Location
    England
    Posts
    36
    Rep Power
    5

    Default

    authTokenControl was introduced as part of the changes for Bug 71479 ? Clear cookie when one parameter is set in Soap Request
    This is from Comment #19 of the bug, which I hope explains it:

    Code:
            Added an optional <authTokenControl voidOnExpired="1"/> element in 
            soap context.  If this element is present, and if the incoming auth 
            token is expired, server will just "void"(i.e. set the mAuthToken 
            field in ZimbraSoapContext to null, as if there is no auth token for 
            the request ) the auth token instead of throwing AUTH_EXPIRED.
    
            The auth token can come in the <authToken> element in soap context, 
            or in a http cookie as a fallback,   <authTokenControl 
            voidOnExpired="1"/> does not distinguish the two cases.   It just 
            applies to the auth token object returned from the AuthProvider.
    
            In other words, if the incoming auth token is expired:
            - If <authTokenControl voidOnExpired="1"/> is not present, server 
            will throw AUTH_EXPIRED exception - nothing changed.
    
            - If <authTokenControl voidOnExpired="1"/> is present:
                  - if a valid auth token is required for the request, server 
            will throw AUTH_REQUIRED.
                  - otherwise, the request will go through
    
    
            <authTokenControl voidOnExpired="1"/> should be used with the 
            ClearCookieRequest.  Usage is when browser sends in expired auth 
            token cookie beyond the control of the web client code.   This 
            problem is triggered becasue we now set httpOnly attribute on auth 
            token cookie, as a result, client cannot get to or clear cookies 
            using javascript.    We can't rely on the Max-Age directive on the 
            cookie - we set Max-Age only when user opts to "remember me" (i.e. 
            ask browser to persist cookies after browser exits.).
    soap.txt does have something to say about <change>:

    Code:
    Race Conditions
    
    To avoid race conditions, the client may specify the highest change ID
    that it knows about in the <change> header element.  The default behavior
    (type="mod") will cause mail.MODIFY_CONFLICT to be thrown if we try to
    modify an object that has been touched (flags, tags, folders, etc.) since
    the specified change ID.  Alternatively, type="new" will throw
    mail.MODIFY_CONFLICT if we try to modify an object that has been created
    or whose content has been modified since the specified change ID.
    
    In general, the sync client will use type="mod" and the web client will
    use type="new".
    In other words, if a modification just involved tagging an item, then if type="mod", mail.MODIFY_CONFLICT would be thrown but if type="new" it wouldn't.

    Hope that helps,
    Gren
    Gren Elliot
    Lead Engineer - Server
    Zimbra | Community & Collaboration

  3. #3
    parin is offline Active Member
    Join Date
    Feb 2013
    Location
    India
    Posts
    28
    Rep Power
    2

    Default

    thank you gren for replying.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. How to read attribute value in soap response
    By hugo@dlshk in forum Zimlets
    Replies: 1
    Last Post: 04-12-2012, 07:59 PM
  2. Soap / attribute questions
    By stan92 in forum Developers
    Replies: 0
    Last Post: 07-22-2010, 08:06 AM
  3. Replies: 1
    Last Post: 03-07-2010, 06:25 AM
  4. invalid request: missing required attribute:
    By Johanna in forum Error Reports
    Replies: 0
    Last Post: 03-04-2010, 02:57 PM
  5. Replies: 2
    Last Post: 12-16-2008, 04: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
  •