As Milan already mentioned we undertook the saga of using the API on a
client basis. We started this ages ago when the API was hardly used by
anyone.
Initially there were a number of bugs in the initial implementation of
the REST function registration, things like not being able to pass in
blank values as opposed to making these required and ensuring that the
signature remained correctly. I am not sure what the state of play is
of the default implementation as we now use our own and very little of
the default implementation.
As part of this process we allow users to create their "own" private
keys. We store their public key as part of the user object leaving the
public/private keys in the API take. This allows us to map into the
user's private key in order to validate the request. By doing this we
actually log the user in thus ensuring that any request they make they
only make on their behalf. That allows us to use the standard access
control methods provided by the framework both for writes and reads.
Although the initial implementation used a HMAC mechanism it was not
identical to that from Amazon (who seem to be setting a standard for
this) thus Milan ensured that we implemented their way and we later on
went to provide client side samples in a number of languages, PHP,
Java, C#, on of our users was kind enough to provide us with a Ruby
version too. We aim to have Javascript and Flash based versions
available as well.
The request for a directory of services is one which we will provide
very soon, the question is just if/how this will be propagated in any
other way into the client i.e. by way of proxy functions or the like,
we'll see, it much depends on how our community reacts to it.
Sam.
On 31 Oct, 15:27, Fx <fx.n...@free.fr> wrote:
> Hi Cash,
> 1. No
> 2. Automated cretion of users and eventually groups, you have probably
> seen my user_rest_create plugin that can automate generic constrcution
> of the api.
> 3. No, it didn't work as i would like. I did an huggly authentication
> inside the code (it's bad, i know, and so unsecure, but it is in an
> intranet context so ...)
> 4. Not with elgg, but used in an other context with ezPublsih and
> Sonic ESB. Simple, and secure enough.
> 5. Hmmmm, it smell a directory of services this !!!! Isn't it. Did you
> plan t provide an index of available services created and the way to
> invoke them as an help ?
> 6. I don't know if it's relevant, but in my cas i needed ton indicate
> who wher the owner of the creation made by the call. Admin seems to be
> evident, but may be
> it would be usefull to let it variable and customisable. For example,
> if a param in the call is set to the user_guid owner's, we could take
> it into consideration, and
> create the objects with this user as owner. If none set, either the
> admin or 'bot' user could be the owner.If we go further and take into
> account hmac, we could use the associated user_key as a key-hashing.
> Regards,
> Fx
> On 13 oct, 12:44, Cash Costello <cash.coste...@gmail.com> wrote:
> > Hi, all
> > I'm working on Elgg's REST implementation and it would be helpful to
> > know how people are using it.
> > 1. Is anyone using it as an external developer facing API (likehttp://www.flickr.com/services/api/asan example)?
> > 2. What other uses do you have for it? (Integration with another open
> > source web application, your own custom desktop application, ...)
> > 3. Is anyone using the REST user authentication token function? How is
> > that working for you?
> > 4. Is anyone using the HMAC signatures?
> > 5. I'm thinking about centralizing the endpoints for the different
> > APIs so they would all live at /services/api/ (/services/api/rest/, /
> > services/api/xml-rpc/, /services/api/export/) and adding a services
> > handler so it is easy to add further services and documentation. Any
> > opinions here?
> > 6. General comments: what could be added to make it work better for
> > you (besides fixing all the bugs)?
> > Thanks,
> > Cash- Hide quoted text -
> - Show quoted text -
