SNP/HTTP fails to retrieve registered applications

[Garulf]

Any check of any registration fails.

Registering
Input:
curl -X POST -H "Content-Type: application/json" "http://10.0.0.50:9597/v2/apps?access_token=a7ea1d69-10d8-464a-96f5-e7243629d816" -d "{ 'app-id': 'app', 'title': 'app' }"

Output:
{ "success": { "app-id": "app" } }

Checking if app has been registered:
Input:
curl -X GET 'http://10.0.0.50:9597/v2/apps/app?access_token=a7ea1d69-10d8-464a-96f5-e7243629d816'

Output:
{ "failed": { "error_number": 101, "error_text": "Failed", "reason": "Application \"app\" isn't registered." } }

Strangley enough I can delete it with no issues:
Input:
curl -X DELETE http://10.0.0.50:9597/v2/apps/app?access_token=a7ea1d69-10d8-464a-96f5-e7243629d816
Output:
{ "success": { "app-id": "app" } }
Noticed the app-id has a "@" character applied to it on the Snarl admin page.

https://drive.google.com/open?id=0B-DXGrGCN6DCT1dORW9USGtqNHM

Not sure if related or not.

[fullphat]

Fixed the issue. There's a further issue to be resolved (Beta 3 now saves the original password used when registering and expects it to match in subsequent registrations, which is a problem for SNP/HTTP as it uses the access token as the password and this changes per session). I'll probably simply remove the password element from SNP/HTTP for now, but I'll give it some thought first.

[Garulf]

Thanks again! I'm checking registration by looking for failed or success object on message send for now.

Hmm if you do keep it would it accept an old session token as a password then? Even if that token was wiped from a crash or Snarl restarting?

Example:
curl -s -X POST -H "Content-Type: application/json" "http://10.0.0.50:9597/v2/apps?access_token=123456" -d "{ 'app-id': 'app', 'title': 'app' }"

Snarl is restarted in some way causing token to be released

curl -X GET 'http://10.0.0.50:9597/v2/apps/app?access_token=123456'

The old token would still work for that app?

[fullphat]

Quick update to keep you in the loop. I'm proposing the following changes to v2:

• No need to authorise/supply access token
• Applications can be password-protected using the x-application-password: header
• All communications can be authorised using the x-authorisation: header (this won't make Beta 3)
• Any computer can register and, once registered, any computer can generate notifications - you can stop rogue users hijacking your app by supplying a password when it's registered (Snarl will record the password used during the first ever registration and - not yet, but soon - will require it in subsequent registrations)

[Garulf]

I agree on the password per app bases it only makes sense and using multiple access tokens as passwords gets confusing fast.

May i propose as a security option a global access-token that can be reset on the admin panel if needed?
This global access token can NOT be retrieved through any API and would have to be supplied manually. Of course being off by default and optional would be nice.

Very similar to how most Oauth token verification works.

This could weed out any unwanted users/programs from spamming you.

[fullphat]

Yep, that's how the other transports work in R5 as well. You can set a password on the transport within Snarl which will then require any application that wants to talk to the listener to supply a key hash and token that Snarl can match to the password. This will be passed in the headers as the HTTP specs seem unclear on whether body content can be included in DELETE requests.