[deepamehta-devel] Developing Third Party Clients with Access Control Module (4.0.12-SNAPSHOT)

[Jörg Richter]

Hi Malte,

thanks for your question!

I can't fully comprehend the situation you describe. With the SNAPSHOT you mention the REST API is not secured at all (just the Webclient frontend is). That is, all REST API requests should be processed without authentication, regardless of PUT or POST. Perhaps there is another problem with your PUT request, which we could investigate separately.

My suggestion:
Work with the current "accesscontrol" branch. That branch will be merged into master soon, and then will become the 4.0.12 release.
Meanwhile the REST API is secured. This means each request is filtered, based on its origin and request method. The filter is controlled by 3 properties in the global POM. The default settings are:

	<dm4.security.read_requires_login>false</dm4.security.read_requires_login>
	<dm4.security.write_requires_login>true</dm4.security.write_requires_login>
	<dm4.security.subnet_filter>127.0.0.1/32</dm4.security.subnet_filter> 

You see, read requests (GET) require no authentication by default, but write requests (POST, PUT, DELETE) do.

For testing purposes you could temporarily set "dm4.security.read_requires_login" to false and restart DM. This switches the filter off and your Firefox plugin should work as before.

To be compatible with DeepaMehta 4.0.12 you should implement authentication in your plugin.
Before issuing any write request you should login. You do so by issuing a GET request:

	GET /accesscontrol/login/{username}/{password}

Username and password must match a DeepaMehta User Account. By default DM comes with one user account: "admin" with an empty password.
The password must be SHA256 encrypted and prepended with "-SHA256-"
So, to login e.g. with the default user:

	GET /accesscontrol/login/admin/-SHA256-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

If login is successful the response consists of
	1) the session ID in the header, e.g.
	    Set-Cookie: JSESSIONID=3xztao4pkpgdc72vxndknef0;Path=/
	2) a Username topic in the payload (JSON)

If login fails the response is 204 No Content.

Ensure the JSESSIONID cookie is included in the header of each of your subsequent requests, e.g.:

	Cookie: JSESSIONID=3xztao4pkpgdc72vxndknef0

For further methods see the REST API of the Access Control plugin:
	AccessControlService.java
	AccessControlPlugin.java

That's great you're updating the Firefox plugin!

Cheers,
Jörg


On Aug 24, 2012, at 17:27, Malte Reißig wrote:

> hello dear developers, dear jri,
> 
> i was wondering if one of you could share with us how a third party client, e.g. the latest "firefox notetaker add-on" or any other proprietary JavaScript client i just started working on, will be able to send create/update and delete (writing) requests to the dm4-webservice module if the dm4-accesscontrol module is installed and active? i am running into strange issues, in which POSTing new topics does work without any authentication (introducing new Web Resources with my firefox plugin does work), but PUTting new values onto a topic (with my new JS client) is silently ignored (topic with former values is returned in response).
> 
> note: i am developing on a 4.0.12-SNAPSHOT of times prior the "dm4.security.*-properties were introduced.
> (to be more precise, on 2f32c7d1f8b1a2ee7588015fe6fcfc044832d384 from the 8th of august).
> 
> i am in the hope that i can update the firefox extension to meet the needs of the upcoming 4.0.12 release and i would be thankful for any explanations or hints regarding this topic to implement the authentication process for users of my new JS client properly.
> 
> cheers!
> malte