Closed (fixed)
Project:
Services
Version:
5.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
1 Mar 2008 at 00:36 UTC
Updated:
18 May 2009 at 02:11 UTC
Jump to comment: Most recent file
I have come up with the use case where I feel we need to make a small change to the way strict keys are coded. Basically I'm setting up a webservice which stores data based on a by client location. Given what we have at the moment the domain has be passed in as a seperate parameter. This provides a security hole as I can pass in my valid hash and then map to a different domain.
The patch attatch allows the key to be accessed as an argument in the under lying webservice call but doesn't change the signature for the webservices module. That way all routing etc is based on the value.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | apikeys.patch | 965 bytes | marcingy |
| api_key.patch | 487 bytes | marcingy |
Comments
Comment #1
marcingy commentedComment #2
marcingy commentedThis patch needs some work as optional parameters will be affected by this if they aren't present as it is just appending to the end of the array.
Comment #3
marcingy commentedTwo options exist as I see it
1. Create a session variable holding the api
2. Create a function which stores a key in static variable and allows services to retrieve its value.
On further review SESSION variables are created in core. I'll take this approach for now and can revisit in the future.
New patch will be rolled in the next couple of days
Comment #4
marcingy commentedpatch using a static variable.
Comment #5
marcingy commentedCan someone review and commit please
Comment #6
magico commentedI think we need to change the way key values are passed.
Instead of:
* having keys enable/disable which break any client developed for the service; and,
* passing 4 parameters when a function uses keys
We should always pass one argument that:
* when keys are enabled in the server, that argument is validated against a authorization scheme
* if keys are disabled the argument is ignored by the server (despite of any that it has)
* the clients are never broken by this
* we have enough flexibility to develop different authorization hash methods
Comment #7
marcingy commented