FYI, we postponed the change (art #9230) for 8.17 (end of july).

Tomas, Patricia,

For your information, we need to make some evolutions there to be aligned with RFC (and reverse proxies):

• POST /artifcat/:id will now return a 201 (instead of 200) as of today
• The "Last-Modified" header will be sent following RFC1123 date (insted of ISO8601) as of today.

Those changes should be transparent to you but feel free to comment to report any problem this might raise

Hi Dylan,

it works very good, thank you.

Hello Patricia,

The build might be available right now.

Hi Dylan, when is this build expected to be available?

For info, the change will be available in Tuleap > 8.4.99.57

Hi, just so I make the right change,

For all requests that return 401 (unauthenticated), you would like the " WWW-Authenticate" header to be

Www-Authenticate: Basic realm="Restricted Tuleap API" Token Realm="Restricted Tuleap API""

thanks

Hi,

ok thank you.

Hello Tomas,

Thanks for your detailed feedback. We will take a look on this with the team in order to fit your needs and the RFCs.
We will come back to you when we will have more information to share with your or a new patch to test in your side.

Hi,

today I tested POST request from FocalPoint to Tuleap and I experienced problems with authentication.
For every POST request I send from Focal Point to Tuleap I receive 401 Unauthorized response.
After some investigation I found out that Tuleap doesn't fully follow Basic access authentication protocol in this case.

The problem is that Focal Point firstly sends POST request without any credentials (according to specification and security reasons) to find out what
authentication methods Tuleap supports.
As response Tuleap should send http response with error code 401 Unauthorize (which it does correctly) and header field named "WWW-Authenticate" containing supported 
authentication methods (Basic, OAuth, ...).

Here is example received from Hansoft, please notice WWW-Authenticate field:

    Status Code: 401 Unauthorized
    Content-Language: en
    Content-Length: 951
    Content-Type: text/html;charset=utf-8
    Date: Thu, 30 Jul 2015 07:28:58 GMT
    Server: Apache-Coyote/1.1
    Set-Cookie: JSESSIONID=24931C6E3380B256E6CA33FEE7A57BB6; Path=/test/; HttpOnly
    WWW-Authenticate: OAuth realm="Hansoft"
                      Basic realm="Hansoft"
                      
But we receive this response from Tuleap:

    Status Code: 401 Unauthorized
    Access-Control-Allow-Credentials: true
    Access-Control-Allow-Headers: Accept, Accept-Charset, Authorization, Content-Type, Origin, X-Auth-UserId, X-Auth-Token
    Access-Control-Allow-Origin: *
    Access-Control-Expose-Headers: X-PAGINATION-SIZE, X-PAGINATION-LIMIT-MAX, X-PAGINATION-LIMIT
    Cache-Control: no-cache, must-revalidate
    Connection: close
    Content-Language: en
    Content-Length: 551
    Content-Type: application/xml; charset=utf-8
    Date: Thu, 30 Jul 2015 07:29:45 GMT
    Expires: 0
    Server: Apache/2.2.15 (Red Hat)
    Vary: Accept
    WWW-Authenticate: Query name="api_key"
    X-Powered-By: Luracast Restler v3.0.0rc6
    
We also noticed that if Tuleap receives POST request with bad credentials then it works fine and Tuleap returns following response:

    Status Code: 401 Unauthorized
    Access-Control-Allow-Credentials: true
    Access-Control-Allow-Headers: Accept, Accept-Charset, Authorization, Content-Type, Origin, X-Auth-UserId, X-Auth-Token
    Access-Control-Allow-Origin: *
    Access-Control-Expose-Headers: X-PAGINATION-SIZE, X-PAGINATION-LIMIT-MAX, X-PAGINATION-LIMIT
    Cache-Control: no-cache, must-revalidate
    Connection: close
    Content-Language: en
    Content-Length: 599
    Content-Type: application/xml; charset=utf-8
    Date: Thu, 30 Jul 2015 13:53:10 GMT
    Expires: 0
    Server: Apache/2.2.15 (Red Hat)
    Vary: Accept
    WWW-Authenticate: Basic realm="Restricted Tuleap API"
                      Query name="api_key"
    X-Powered-By: Luracast Restler v3.0.0rc6

And here is body of response:

<?xml version="1.0" encoding="UTF-8"?>

<response>
    <error>
        <code>401</code>
        <message>Unauthorized</message>
    </error>
    <debug>
        <source>Restler.php:940 at authenticate stage</source>
        <stages>
            <success>
                <text>get</text>
                <text>route</text>
                <text>negotiate</text>
            </success>
            <failure>
                <text>authenticate</text>
                <text>message</text>
            </failure>
        </stages>
    </debug>
</response>

 

You can check more information here:    

10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].

Source: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

Protocol
Server side
When the server wants the user agent to authenticate itself towards the server, it must respond appropriately to unauthenticated requests.
Unauthenticated requests should return an HTTP 401 Not Authorized response code containing a WWW-Authenticate HTTP header.[5]
The WWW-Authenticate header for basic authentication (used most often) is constructed as following:

WWW-Authenticate: Basic realm="nmrs_m7VKmomQ2YM3:"

Source: https://en.wikipedia.org/wiki/Basic_access_authentication

Hi,

I tested lates build and it works fine.

yes you are right, version running on testing server is 8.4.99.21. Thanks

Are you testing on Tuleap 8.4.99.22 ? Because on my side, when the POST returns 200, I've got:

"Date": "Mon, 27 Jul 2015 10:08:40 GMT",
"Server": "Apache/2.2.3 (CentOS)",
"X-Powered-By": "Luracast Restler v3.0.0rc6",
"Vary": "Accept,User-Agent",
"Allow": "OPTIONS, POST",
"Access-Control-Allow-Methods": "OPTIONS, POST",
"Last-Modified": "2015-07-27T12:08:40+02:00",
"Etag": "1437991720",
"Location": "https://sonde.cro.enalean.com/api/v1/artifacts/8491?values_format=by_field",
"Cache-Control": "no-cache, must-revalidate",
"Expires": "0",
"Content-Language": "en-US",
"Access-Control-Allow-Origin": "*",
"Access-Control-Allow-Credentials": "true",
"Access-Control-Allow-Headers": "Accept, Accept-Charset, Authorization, Content-Type, Origin, X-Auth-UserId, X-Auth-Token",
"Access-Control-Expose-Headers": "X-PAGINATION-SIZE, X-PAGINATION-LIMIT-MAX, X-PAGINATION-LIMIT",
"Content-Length": "255",
"Keep-Alive": "timeout=15, max=100",
"Connection": "Keep-Alive",
"Content-Type": "application/xml; charset=utf-8"
}

Hi,

I tested latest build today, please look at http response of POST request, there is no "Location" field in header.

    Status Code: 200 OK
    Access-Control-Allow-Credentials: true
    Access-Control-Allow-Headers: Accept, Accept-Charset, Authorization, Content-Type, Origin, X-Auth-UserId, X-Auth-Token
    Access-Control-Allow-Methods: OPTIONS, POST
    Access-Control-Allow-Origin: *
    Access-Control-Expose-Headers: X-PAGINATION-SIZE, X-PAGINATION-LIMIT-MAX, X-PAGINATION-LIMIT
    Allow: OPTIONS, POST
    Cache-Control: no-cache, must-revalidate
    Connection: close
    Content-Language: en
    Content-Length: 249
    Content-Type: application/xml; charset=utf-8
    Date: Mon, 27 Jul 2015 09:57:57 GMT
    Etag: 1437991077
    Expires: 0
    Last-Modified: 2015-07-27T11:57:57+02:00
    Server: Apache/2.2.15 (Red Hat)
    Set-Cookie: TULEAP_session_hash=1fe7f0caa159dea7b0fe88c5179e3b8c; path=/; domain=.openalm-dev.lmera.ericsson.se; httponly
    TULEAP_user_token=5081faba121322def20c2b349b56b3e3; expires=Tue, 28-Jul-2015 09:57:57 GMT; path=/; domain=.openalm-dev.lmera.ericsson.se
    TULEAP_user_id=13156; path=/; domain=.openalm-dev.lmera.ericsson.se
    Vary: Accept
    X-Powered-By: Luracast Restler v3.0.0rc6

The Location header is merged in Tuleap 8.4.99.22

A patch is under review to add the Location header: gerrit #4261

ok, thank you.

Thanks for sharing this Thomas. We will add this location header for GET and POST artifacts/:id

Here is example of http response header returned to Focal Point from another tool called Hansoft, please see field called Location.



Status Code: 201 Created
Content-Type: application/rdf+xml
Date: Fri, 24 Jul 2015 07:47:04 GMT
Etag: 1437724024198
Location: http://ESEKIWDP2526.RND.ERICSSON.SE:8443/test/services/tasks/3395
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked

URL "http://ESEKIWDP2526.RND.ERICSSON.SE:8443/test/services/tasks/3395" can be used for updates (PUT) or fetch (GET) of task with id 3395.

Maybe I was wrong here, I ment complete URL to artifact. URL which can be used for updates of artifact.
Usually it is returned in responses (with an HTTP status code of 201 or 202) from an HTTP server in the HTTP Location header field to provide information about the location of a newly created resource.

What do you mean by complete "URI" ? Can you provide me an example please ?

Hi Yannis,

please add there complete URI of artifact, because Focal Point uses the URI provided in POST response for updates (PUT) of artifact.

Hello Patricia,

The patch was just merged. It will be available in Tuleap 8.4.99.20 in the next minutes (when the packages will be built).

Hi Yannis, please let us know when a build is available so that we can try it out. Many thanks

You are right, it was missing.

So when you create an artifact by field with post, it will add ?values_format=by_field in the URI.

Examples

1. With values_by_field -> artifacts/8490?values_format=by_field
2. With values -> artifacts/8490

 

A patch is under review to add this parameter in the returned URI: gerrit #4259

Hello @xtomaza, I will check that.

Hi,

I tested new POST method today. It looks good. I have just comment, seems that POST response (201 created) doesn't return the parametrized url in response header.

Could you please check it ?

Hi Patricia,

I've just merged the POST route. It's available in Tuleap 8.4.99.4.

Regards,

Hi, when can we expect the build that contains the POST route? Thanks

Hello Thomas. Thanks for your feedback.

Regarding the POST route, it is not as of today integrated into Tuleap (still under review here: https://gerrit.tuleap.net/#/c/4204/). We will come back to you when the POST will be merged into Tuleap.

The change for GET (gerrit #4215) is integrated into Tuleap 8.3.99.36. Could you please (re)test?

We made some changes to the GET route in order to be more consistent with the existing value format.

Now with GET /artifacts/:id, you will have something like this:

GET /artifacts/:id?…
    200 Ok
    <response>
        <id>42</id>
        ...
        <values>
            <item>
                <field_id>12</field_id>
                <type>float</type>
                <name>story_points</name>
                <label>Story Points</label>
                <value>1.6</value>
            </item>
        </values>
        <values_by_field>
            <story_point>
                <field_id>12</field_id>
                <type>float</type>
                <name>story_point</name>
                <label>Story Point</label>
                <value>1.6</value>
            </story_point>
        </values_by_field>
    </response>

The GET route now returns only alphanumeric fields (no more list and date fields) to be consistent with what the POST route can handle.

For the POST route, you will have to provide something like this:

POST /artifacts/:id
    <artifact>
        <values_by_field>
            <story_points>
                <value>3.14</value>
            </story_points>
        </values_by_field>
    </artifact>
    200 Ok

if you submit to the POST route the additional information you retrieved with GET, like "field_id", "label", "name" or "type", the POST route will ignore them and only take into account "value".

These two patches are currently under review, we will notify you when they are merged so you can test them.

For your information a first step is available in Tuleap 8.3.99.28. You can now parameterize the GET route in order to retrieve artifact values indexed by field. Example:

GET /artifacts/4096?values_format=by_field
{
  "id": 4096,
  "uri": "artifacts/4096",
  ...,
  "values": null,
  "values_by_field": {
    "story_points_11": 3.14,
    "i_want_to": "see the Start and End Date of a Release in all views",
    ...
  }
}

Please note that only a subset of field types are supported:

• Field int/float
• Field string/text
• Field lists (selectbox, multi selectbox, radio button, checkbox)
• Field open lists
• Field date (with and without time)

Could you please check on your side that this is the intended behavior?

We are currently working on the POST operation.