Convert paramaters for auth methods into an array

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.

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.

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

First step of making methods plugable has now been done this should be worked on as a follow up to simplify structures.

Waiting on the decoupling of methods being finalised so as we know what the structures will look like.

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

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.

Updating version

So I talked to Marc and Hugo about this on IRC the other day, and the current plan is to change it as follows:

1) Auth parameters go to the end of the function signature instead of the beginning
2) It becomes an associative array of data, instead of individual parameters

Sound good to everyone?

You may also want to follow the happenings at

http://drupal.org/node/465546#comment-2830184

Hi HeyRocker,

while it sounds great that it will be an associative array of data (which allows different mechanisms to be implemented), I'm not sure about it being the last argument in the method signature.
When security is implemented as an assoc array, it's part of EVERY method signature, independent of the other arguments.

Giving it a fixed place as the first argument will make sure that every method signature is consistent, which is very desirable.
Any thoughts?

Moving to current version and setting as postponed for consideration in 7.4

I realize now that this isn't about the amf method signature but about the services php side of handling it. in which case my argument does not make sense.
I thought it was also about how data was sent from an actionscript client, which is only relevant for amf servers and then only for that specific server implementation.

previous comments can be ignored

This really only holds true for 6.x.2 as the signature was flexible the new system allows way round this.