URL to editing report contain report_id

[kbeker]

Currently during editing report we can change edited report to any other which already is created in database. ID should be handled from request body instead of URL.

Current state:

http://sheetstorm.codepoets.it/report/1

Recommended state:

http://sheetstorm.codepoets.it/report/

[rwrzesien]

This shouldn't be done this way (I mean that ID should stay in the url), but we should secure the access/actions on the report to particular users/groups.
I think that Read/Update/Delete action could be performed by:

• author of the report
• admin
  I think that Read/Update action could be performed by:
• project managers

@Karrp @kbeker What do you guys think?

[Karrp]

@rwrzesien Why not request body instead of URL?

I think that Read/Update/Delete action could be performed by:

author of the report
admin
I think that Read/Update action could be performed by:
project managers

is ok

[rwrzesien]

@Karrp

Why not request body instead of URL?

Nice try :) But we first render page using HTTP GET request, and this type of request shouldn't contain anything in the body. It is possible, but its against all rules and can cause unexpected problems on many layers. We also use POST for submitting the form, so then we should use different url for rendering form and different for submitting, and we have to pass the value from the body from one to another, but actually client can modify it between requests... this is just the pick of the mountain of incoming problems with this :)

If we want to somehow hide the database ids from the url (which is not really needed now in my opinion, but can be nice improvement in the future) we can replace them with some unique uuids generated for each user.

is ok

OK, I will use this info when working on #45

@Karrp @kbeker So I think we can close this issue, I think it will be fully secured in the code itself, even if someone will modify the url and don't have correct rights he will be redirected to different page.

[kbeker]

@Karrp @kbeker So I think we can close this issue, I think it will be fully secured in the code itself, even if someone will modify the url and don't have correct rights he will be redirected to different page.

@rwrzesien I will test it during review, but at first sight it looks like it should be all secured :)