Convert paramaters for auth methods into an array
magico - September 29, 2008 - 08:39
| Project: | Services |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | marcingy |
| Status: | postponed |
Jump to:
Description
The keys authorization method should be changed to:
* Just use one argument. This should be implemented, so we can change the key authorization method without having to always change the services consumer application
* 5 arguments are simply too many just to do key authorization
* We should have different (and pluggable) keys mechanisms (eg: OAuth), and we only can have this, if we have a generic mechanism of sending key data through any service
* Because we can have services using keys and others not, and just by using site configuration we can force services to use them or not
I think this is a critical feature, to have a definitive authorization mechanism within the services project!
#1
#2
I would love to see key authentication be a plugin so we can use oauth or other hash methods. I agree the 5 arguments is a bit much.
#3
My first thought is that the parameters that are key specific should be passed in as an array. That array should should include the protocol being utilised as one of its parameters or it should be passed in out with the array. The server would then need to define what protocols are available and process the request based on the speficied values.
#4
I agree. An array of key parameters, including the protocol to be used.
I also think that this parameter should always exist and be passed to the service, even if the server is configured to not use keys. This way, we can always implement the client with those parameters and not break the service if we choose to disable/enable the keys on the server.
#5
My view is that a protocao should always be specificed in the array even if the server allows open communication just for consistency.
If this was the ws the case the array passed would look like this
array = ('protocol' => 'none')otherwise
array = ('protocol' => 'services_key', 'nonce' => $nonce, 'timestamp' => $timestamp.....);The server would then check to see which protocols are enabled on the server. If the protocol specified is enabled then the request is processed otherwise the client should be returned a error message that the protocol is not supported, unless the given method didn't require a key to be provided. What are your thoughts on a new hook being exposed hook_services_protocol. This would allow protocols that are available to register themselves with the services module, and specify what parameters are required in the array. In addition I think we need a second hook hook_services_protocol_validate. This would be responsible for handling validation of the keys etc and would simply return TRUE or FALSE to the services module.
Each protocol should be enabled from the current admin screen. This would mean that the current enable keys option would be removed and instead a protocol specific option would be present e.g Services Keys, Oauth etc along with a clear description of what it means and parameters expected. If no protocols are enabled then the server should allow requests to be processed freely.
I also have the feeling that the services browser would need to be rewritten and would end up being protocol specific, or at the very least allow the protocol being used to be selected.
Thoughts
#6
I agree with everything you said.
With respect to the service browser I think that it should be implemented *without* (and bypassing) the protocol validation. In fact, the service browser is used only in the admin section and for testing purposes. Right? Or the idea is too be used by everyone...?
#7
First step of making methods plugable has now been done this should be worked on as a follow up to simplify structures.
#8
Waiting on the decoupling of methods being finalised so as we know what the structures will look like.
#9
#10
Hi, as the author of one of the flash as3 frameworks for communicating from flash to drupal via amf/remoting (www.dpdk.nl/opensource), it was actually one of my major criticisms I had, since it is an enormous pain for the client code to implement the different cases. It would make life much simpler for everybody if everything was routed via one object/assoc array as the first (compulsory) parameter to the different service methods.
I agree 100%, this would be SUPER if this was implemented.
We'd also upgrade our as3 flash code immediately to make use of the newer functionality and make it available to the drupal community.
thanks and good luck
#11
My problem with this, as it is with many of the patches around authentication, is that it is going to break every site installation using Services, and I'm not really willing to do that without starting a new branch. We have over 4,000 installations right now and almost all of them are using keyauth. To just up and break all their code is irresponsible IMO.
That said, I realize the current authentication system is very painful to work with. After we release a stable 2.x I'll open up a 3.x and start porting to Drupal 7. I highly encourage everyone to get involved at that time.
Marking this as postponed so we don't lose it.