Ticket #767 (closed Defect: fixed)

Opened 7 years ago

Last modified 7 years ago

Cannot assign a topic to a workspace through the REST API

Reported by: JuergeN Owned by: jri
Priority: Major Milestone: Release 4.6
Component: DeepaMehta Standard Distribution Version: 4.5
Keywords: Cc:
Complexity: 3 Area: Application Framework / API
Module:

Description

Hi! I am trying to assign a newly created topic to a workspace:

    curl -sX POST -H Content-Type:application/json -H "Authorization: Basic ${ADMPW}" ${SERVER}:${PORT}/workspace/${WSID}/topic/${TOPICID}

Command fails with 404 not found.

Change History

comment:1 Changed 7 years ago by JuergeN

I want to make up the whole picture: As a user I want to use curl to dump some data into DeepaMehta. I want to authenticate as the actual user and become the creator and owner of the newly created objects. Also I want to be able to assign them to the workspace of my choice, amongst those where I have write access.

comment:2 Changed 7 years ago by jri

To (re)assign a topic/association to a workspace:

curl -X PUT -H 'Authorization: Basic YWRtaW46' http://localhost:8080/workspace/2776/object/2846

Here 2776 is the workspace ID and 2846 is the topic/association ID.

So:

  • you need PUT instead of POST
  • it must be /object (instead /topic) as this request works for associations as well. In DM jargon object stands for topic or association.
  • you don't need the Content-Type header as you don't send any content (as with -d). The header doesn't disturb anyway.

However, it is easier when you assign a workspace just along with creating the topic, by the means of the workspace cookie.

To create e.g. a Note topic and assign it to a workspace right away:

curl -X POST -H 'Authorization: Basic YWRtaW46' -H 'Cookie: dm4_workspace_id=2301' -H 'Content-Type: application/json' -d '{
    type_uri: "dm4.notes.note",
    childs: {
        dm4.notes.title: "My Note",
        dm4.notes.text: "<p>HTML content here</p>"
    }
}' http://localhost:8080/core/topic

Here 2301 is the workspace ID.
The topic's owner is the owner of the workspace then (as shown with the Webclient's Get Info command).
The topic's creator and modifier will be the authenticated user (according to the Authorization header).

As you know YWRtaW46 is the Base64 encoded version of the string username:password. You can do Base64 encoding e.g. with the browser's JavaScript? console, by calling JavaScript?'s btoa function.

Example:

btoa("janet:123456")

The result is amFuZXQ6MTIzNDU2 then.

Last edited 7 years ago by jri (previous) (diff)

comment:3 follow-up: ↓ 5 Changed 7 years ago by JuergeN

Thank you very much! Got it working! :) Took me a while though to find out how to do the base64 enconding properly in bash. Here it is:

echo -n "testuser:testpass" | openssl base64 -e

which should result in

dGVzdHVzZXI6dGVzdHBhc3M=

Btw. my idea is to write a little script that will allow me to put my contacts into DeepaMehta. I will read them from vcf files and convert them in json.

Last edited 7 years ago by JuergeN (previous) (diff)

comment:4 follow-up: ↓ 6 Changed 7 years ago by JuergeN

Haha, here comes the next challenge: Is there a scripted way to find out the id of my "Private Workspace". From what I can see it does not have an URI.

comment:5 in reply to: ↑ 3 Changed 7 years ago by jri

Replying to JuergeN:

Thank you very much! Got it working! :)

Very good!
:-)

Just one thought about HTTP sessions: DM creates a new session for every request that contains no JSESSIONID cookie but an Authorization header. Furthermore DM's default config disables session timeout (that is sessions live forever). So your webserver will run out-of-memory someday. You could consider one of these approaches:

  • In DM's config.properties set org.ops4j.pax.web.session.timeout=60 to have a session timeout of 1 hour.
  • Reuse the session created with the 1st request for the subsequent requests. To do so you could send a login request first:
    curl -X POST -H 'Authorization: Basic YWRtaW46' http://localhost:8080/accesscontrol/login
    

In case of a successful login the response is a 204 (No Content) along with a Set-Cookie header that tells you the ID of the created session:

HTTP/1.1 204 No Content
Set-Cookie: JSESSIONID=ma0tb5f4pytf12q2j6a4r6k3z;Path=/
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: application/json
Server: Jetty(8.y.z-SNAPSHOT)

You have to extract the session ID and send it along with each of your subsequent requests in a Cookie header:

curl ... -H 'Cookie: JSESSIONID=ma0tb5f4pytf12q2j6a4r6k3z' ...

Note: you need no Authorization header in the subsequent requests then.

Tell me if you need any help.

And thanks for the base64 command line!
:-)

PS: I'll answer to your private workspace question very soon

comment:6 in reply to: ↑ 4 Changed 7 years ago by jri

Replying to JuergeN:

Haha, here comes the next challenge: Is there a scripted way to find out the id of my "Private Workspace".

The Access Control API provides a getPrivateWorkspace() method already, however it is not yet RESTful. I filed a ticket (#768) and will fix that very soon in the 4.6-SNAPSHOT line of development (master branch).

From what I can see it does not have an URI.

Yes, currently the private workspaces have no dedicated URI.

comment:7 follow-up: ↓ 8 Changed 7 years ago by jri

Now you can get the private workspace via REST, see ticket:768#comment:2.
To get the actual workspace ID you have to extract it from the response topic (just like in #763).
You must update your master branch.
Let me know if you need any help.

comment:8 in reply to: ↑ 7 Changed 7 years ago by jri

Replying to jri:

Now you can get the private workspace via REST, see ticket:768#comment:2.

Here is the explicit curl command:

curl -H 'Authorization: Basic YWRtaW46' http://localhost:8080/accesscontrol/user/workspace

You'll get the private workspace of the authenticated user.

comment:9 Changed 7 years ago by jri

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.