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)?
2) I'm using it primarily from JavaScript AJAX calls, where the user
is already authenticated. I'm using it instead of actions because
there's less overhead setting one up and actions always do a forward
after the action finishes.
3/4) I will need some external authentication, but the lack of a good
template and time to figure out usage on my own has preventing me from
using it just yet.
5) I'm only using REST; haven't yet had a need for a different kind of
service (although examples of the others might spur my imagination).
For services that are simply alternative approaches to IPC, I don't
know that providing N options buys you anything but confusion. Go
with one and make it work flawlessly, rather than half-assed
implementations of several.
6) The actual responses look kind of verbose (I think in JSON there's
an object with a single "api" field, which has "result" in it; the
extra level seems extraneous).
There are no good examples of error handling. The typical ways of
signaling an error in PHP (throw an excaeption, return false) all
result in the API failing, instead of generating an error result. I
figured out the only way to return an error is to return an
ErrorResult; it'd be nicer to simply throw an exception and have the
REST handler handle the error. That way my exposed functions can be
used by regular code without having API warts on it.
I'm using the Elgg RESTApi for importing users and their data from an
existing community to elgg. So I created some functions which extends
the RESTApi.
One thing I miss is the availability of Api-Users. At the moment I use
an admin-user for loggin in into the community.
I saw that there tables in the database for api-users and api-session
but I was not able to figure out how it works.
So what is planned to open the RESTApi to a extra group of users which
are not normal members of the community?
Just as Google, Flickr, and others require developers to register and
obtain an API key to use their web services, Elgg has a built-in API
key system. If you ever wanted to expose your REST-like API to
external developers, it would come in handy for tracking who is doing
what. I'm planning on making this more extensible in the next version.
You shouldn't need a user logged in to import data. A permissions
override should allow you to write to the database using the Elgg data
model classes. If you want an example of a permissions override, my
trackbacks plugin should be a simple demonstration of this:
http://community.elgg.org/pg/plugins/costelloc/read/204054/trackbacks
On Oct 17, 5:19 am, Thomas <thomas.winkelm...@gmail.com> wrote:
> I'm using the Elgg RESTApi for importing users and their data from an
> existing community to elgg. So I created some functions which extends
> the RESTApi.
> One thing I miss is the availability of Api-Users. At the moment I use
> an admin-user for loggin in into the community.
> I saw that there tables in the database for api-users and api-session
> but I was not able to figure out how it works.
> So what is planned to open the RESTApi to a extra group of users which
> are not normal members of the community?
2) I'm working on integrating Elgg and Moodle to some extent. We're
planning to use Elgg to add social functionalities to Moodle courses
and transfer some content from Elgg to Moodle.
3) I tried this but I couldn't get it to work unless the script in
Moodle sent username and password in every call to Elgg. Using this
method also seemed to logout the user from Elgg if he/she was using
Elgg at the same time.
4) I tried this as well, but couldn't get it working at all.
5) Sounds like a good idea!
I'm really looking forward to the next version, it's great that you're
working on this!
First version of the new implementation has been committed to the svn
repository. It should fix most of the bugs with the old API. There
will be more changes, but the core is there now.
Fixes:
1. POST should work now
2. Full control over API authentication and user authentication
* these two have been separated so you can now implement whatever
API authentication you want (with 2 default options)
* you can control what authentication is used by the REST service
with a plugin hook
3. You can throw exceptions in your exposed functions and they are
turned into API results for you
4. Several other bug fixes
Outstanding issues:
1. Elgg's session implementation currently makes it impossible to use
an auth token while a user is logged in using browser
2. XML output still has some issues (is it too verbose with all the
info on type?)
3. I'm still working through centralizing the endpoints. I don't plan
to implement any additional services but make it easy for anyone to
add a service (example: maybe someone wants json as both the input and
output of a service)
Note that api.php has a hook into Elgg's new unit testing framework
but you won't be able to use that without grabbing more files from
svn. Also, currently the schema in SVN has a bug which breaks the
activity river.
Cash
On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
1) Yes - I think we are, but not open sourced api's
2) Created elgg based web services
3) See 4!
4) We're using the HMAC signatures or to be accurate we tried to use
them and found them to not be compatible with other tool sets and
languages. The problem I think was that the HMAC was calculated into
hex values and not encoded into a standard canonicalized format which
doesn't change across toolkits.
a) The actually format of the string to sign wasn't normalised to
UTF-8 (not normally an issue, but can be)
b) The hmac isn't generated using binary values (see:
http://php.net/manual/en/function.hash-hmac.php)
c) If the hmac is in binary then the output of this can be base64
encoded into a standard strict format, which is built into nearly
every language by default (apart from *cough* java where you need a
external jar).
Why do this? As other languages by default out put binary values from
the HMAC and also the hex output is generally unpredictably different.
We also did away with doing different Hashes for POST and GET.
Basically we had a look at the Amz S3 model and then overloaded the
current API - I think.
As for 5) and 6), i'll ask Sammy as he done more API work than I have!
Milan
On Oct 22, 2:40 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> Note that api.php has a hook into Elgg's new unit testing framework
> but you won't be able to use that without grabbing more files from
> svn. Also, currently the schema in SVN has a bug which breaks the
> activity river.
> Cash
> On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > Hi Cash and everybody.
> > to answer your survey:
I've used php and java with the current hmac without any problems (and
I did not write it). I'm going to look into making it compatible with
OAuth: http://oauth.net/core/1.0#anchor16
I've add a simple api auth method that just requires the public key.
This is probably sufficient for using the API to integrate
applications and for a lot of external facing uses, too.
I noticed from your client that you are using more than GET and POST.
That's also something that I've kicked around but wasn't sure anyone
would use it.
On Oct 23, 7:15 am, milan <mi...@magudia.com> wrote:
> 1) Yes - I think we are, but not open sourced api's
> 2) Created elgg based web services
> 3) See 4!
> 4) We're using the HMAC signatures or to be accurate we tried to use
> them and found them to not be compatible with other tool sets and
> languages. The problem I think was that the HMAC was calculated into
> hex values and not encoded into a standard canonicalized format which
> doesn't change across toolkits.
> a) The actually format of the string to sign wasn't normalised to
> UTF-8 (not normally an issue, but can be)
> b) The hmac isn't generated using binary values (see:http://php.net/manual/en/function.hash-hmac.php)
> c) If the hmac is in binary then the output of this can be base64
> encoded into a standard strict format, which is built into nearly
> every language by default (apart from *cough* java where you need a
> external jar).
> Why do this? As other languages by default out put binary values from
> the HMAC and also the hex output is generally unpredictably different.
> We also did away with doing different Hashes for POST and GET.
> Basically we had a look at the Amz S3 model and then overloaded the
> current API - I think.
> As for 5) and 6), i'll ask Sammy as he done more API work than I have!
> Milan
> On Oct 22, 2:40 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > Hi, Antoine
> > If you're just starting out, I recommend grabbing the latest REST api
> > from svn because it has a lot of bug fixes. The files you need are:
> > Note that api.php has a hook into Elgg's new unit testing framework
> > but you won't be able to use that without grabbing more files from
> > svn. Also, currently the schema in SVN has a bug which breaks the
> > activity river.
> > Cash
> > On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > > Hi Cash and everybody.
> > > to answer your survey:
Hi Cash,
thanks for the heads up I am just starting with the API :)
btw I had to tweak the authentification in api.php (in both the last
rev and the previous one)
in the execute_method fct inside the foreach the api checks for $value
['required'] but this field doesn't exist wich made it throw an
exeption like "missing parameter username"
Best,
Antoine.
On Oct 22, 3:40 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> Note that api.php has a hook into Elgg's new unit testing framework
> but you won't be able to use that without grabbing more files from
> svn. Also, currently the schema in SVN has a bug which breaks the
> activity river.
> Cash
> On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > Hi Cash and everybody.
> > to answer your survey:
Antoine, parameters are required unless specified otherwise in the
expose_method(). If a required parameter is not passed, an exception
is the expected result.
On Oct 23, 8:41 am, Ant- <antoine.raba...@gmail.com> wrote:
> Hi Cash,
> thanks for the heads up I am just starting with the API :)
> btw I had to tweak the authentification in api.php (in both the last
> rev and the previous one)
> in the execute_method fct inside the foreach the api checks for $value
> ['required'] but this field doesn't exist wich made it throw an
> exeption like "missing parameter username"
> Best,
> Antoine.
> On Oct 22, 3:40 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > Hi, Antoine
> > If you're just starting out, I recommend grabbing the latest REST api
> > from svn because it has a lot of bug fixes. The files you need are:
> > Note that api.php has a hook into Elgg's new unit testing framework
> > but you won't be able to use that without grabbing more files from
> > svn. Also, currently the schema in SVN has a bug which breaks the
> > activity river.
> > Cash
> > On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > > Hi Cash and everybody.
> > > to answer your survey:
The current Elgg REST API is not really RESTful but more of a REST/RPC
hybrid approach (similar to Twitter, Facebook, Flickr). It is not
structured well to handle more than GET/POST in a nontrivial fashion.
As such, I think I'm going to stick with the current GET/POST
restrictions. Any comments?
On Oct 23, 8:30 am, Cash Costello <cash.coste...@gmail.com> wrote:
> I've used php and java with the current hmac without any problems (and
> I did not write it). I'm going to look into making it compatible with
> OAuth:http://oauth.net/core/1.0#anchor16
> I've add a simple api auth method that just requires the public key.
> This is probably sufficient for using the API to integrate
> applications and for a lot of external facing uses, too.
> I noticed from your client that you are using more than GET and POST.
> That's also something that I've kicked around but wasn't sure anyone
> would use it.
> On Oct 23, 7:15 am, milan <mi...@magudia.com> wrote:
> > 1) Yes - I think we are, but not open sourced api's
> > 2) Created elgg based web services
> > 3) See 4!
> > 4) We're using the HMAC signatures or to be accurate we tried to use
> > them and found them to not be compatible with other tool sets and
> > languages. The problem I think was that the HMAC was calculated into
> > hex values and not encoded into a standard canonicalized format which
> > doesn't change across toolkits.
> > a) The actually format of the string to sign wasn't normalised to
> > UTF-8 (not normally an issue, but can be)
> > b) The hmac isn't generated using binary values (see:http://php.net/manual/en/function.hash-hmac.php)
> > c) If the hmac is in binary then the output of this can be base64
> > encoded into a standard strict format, which is built into nearly
> > every language by default (apart from *cough* java where you need a
> > external jar).
> > Why do this? As other languages by default out put binary values from
> > the HMAC and also the hex output is generally unpredictably different.
> > We also did away with doing different Hashes for POST and GET.
> > Basically we had a look at the Amz S3 model and then overloaded the
> > current API - I think.
> > As for 5) and 6), i'll ask Sammy as he done more API work than I have!
> > Milan
> > On Oct 22, 2:40 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > > Hi, Antoine
> > > If you're just starting out, I recommend grabbing the latest REST api
> > > from svn because it has a lot of bug fixes. The files you need are:
> > > Note that api.php has a hook into Elgg's new unit testing framework
> > > but you won't be able to use that without grabbing more files from
> > > svn. Also, currently the schema in SVN has a bug which breaks the
> > > activity river.
> > > Cash
> > > On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > > > Hi Cash and everybody.
> > > > to answer your survey:
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:
> 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)?
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.
> 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.
> > 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 for the tip. I updated those files, but something make me
scratch my head...
I need to authenticate the user, first with simple GET (without HMAC).
When I use:
- expose_function(... , 'GET', false, false), user is not
authenticated,
- expose_function(... , 'GET', false, true), it returns an error,
because user is not authenticated even with username and password
parameters.
But when looking at the usage of pam_auth_userpass($credentials) in
api.php, it looks like it is never called with the right user/password
credentials.
My question is : do I need to correct this ? and initiate credentials
(from $_GET or $_POST) in pam_auth_userpass(), or in the caller
function ?
On 22 oct, 14:40, Cash Costello <cash.coste...@gmail.com> wrote:
> Note that api.php has a hook into Elgg's new unit testing framework
> but you won't be able to use that without grabbing more files from
> svn. Also, currently the schema in SVN has a bug which breaks the
> activity river.
> Cash
> On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > Hi Cash and everybody.
> > to answer your survey:
1. Passing username and password with GET is a bad idea. The password
will be written to your web server log.
2. I recommend using the user token. You first make a call that passes
the username and password (using POST). You are returned a user token
that is good for 1 hour by default. Now in every subsequent call for
that user, pass the token as the parameter "auth_token".
3. I plan to remove the option passing the username and password on
every call by default. Developers will be able to turn it on though
definitely not recommended.
4. You also have the option of building your own user authentication
module. Without knowing your application I can't tell if it is a good
fit for you.
On Nov 4, 9:39 am, "Phil.T" <tran....@gmail.com> wrote:
> Thanks cash for the tip. I updated those files, but something make me
> scratch my head...
> I need to authenticate the user, first with simple GET (without HMAC).
> When I use:
> - expose_function(... , 'GET', false, false), user is not
> authenticated,
> - expose_function(... , 'GET', false, true), it returns an error,
> because user is not authenticated even with username and password
> parameters.
> But when looking at the usage of pam_auth_userpass($credentials) in
> api.php, it looks like it is never called with the right user/password
> credentials.
> My question is : do I need to correct this ? and initiate credentials
> (from $_GET or $_POST) in pam_auth_userpass(), or in the caller
> function ?
> On 22 oct, 14:40, Cash Costello <cash.coste...@gmail.com> wrote:
> > Hi, Antoine
> > If you're just starting out, I recommend grabbing the latest REST api
> > from svn because it has a lot of bug fixes. The files you need are:
> > Note that api.php has a hook into Elgg's new unit testing framework
> > but you won't be able to use that without grabbing more files from
> > svn. Also, currently the schema in SVN has a bug which breaks the
> > activity river.
> > Cash
> > On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > > Hi Cash and everybody.
> > > to answer your survey:
> 1. Passing username and password with GET is a bad idea. The password
> will be written to your web server log.
> 2. I recommend using the user token. You first make a call that passes
> the username and password (using POST). You are returned a user token
> that is good for 1 hour by default. Now in every subsequent call for
> that user, pass the token as the parameter "auth_token".
> 3. I plan to remove the option passing the username and password on
> every call by default. Developers will be able to turn it on though
> definitely not recommended.
> 4. You also have the option of building your own user authentication
> module. Without knowing your application I can't tell if it is a good
> fit for you.
> On Nov 4, 9:39 am, "Phil.T" <tran....@gmail.com> wrote:
> > Thanks cash for the tip. I updated those files, but something make me
> > scratch my head...
> > I need to authenticate the user, first with simple GET (without HMAC).
> > When I use:
> > - expose_function(... , 'GET', false, false), user is not
> > authenticated,
> > - expose_function(... , 'GET', false, true), it returns an error,
> > because user is not authenticated even with username and password
> > parameters.
> > But when looking at the usage of pam_auth_userpass($credentials) in
> > api.php, it looks like it is never called with the right user/password
> > credentials.
> > My question is : do I need to correct this ? and initiate credentials
> > (from $_GET or $_POST) in pam_auth_userpass(), or in the caller
> > function ?
> > On 22 oct, 14:40, Cash Costello <cash.coste...@gmail.com> wrote:
> > > Hi, Antoine
> > > If you're just starting out, I recommend grabbing the latest REST api
> > > from svn because it has a lot of bug fixes. The files you need are:
> > > Note that api.php has a hook into Elgg's new unit testing framework
> > > but you won't be able to use that without grabbing more files from
> > > svn. Also, currently the schema in SVN has a bug which breaks the
> > > activity river.
> > > Cash
> > > On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > > > Hi Cash and everybody.
> > > > to answer your survey:
Phil - add your own user PAM. The API does not set the user
credentials so the default one does not return true. You could use the
plugin hook in /services/api/rest.php to add your PAM whenever the
REST api is used.
On Nov 5, 7:37 am, "Phil.T" <tran....@gmail.com> wrote:
> i dont use the token to get everything in 1 shot: authentification and
> rest/rpc stuff, no waste of time (many transactions) and bandwith
> and i plan to get first the GET working, then post user pwd (passing
> username in the url), and then use HMAC
> data load would also be in the post. hence the idea to use pam-aut-
> userpass.
> how do u think I could I do this ?
> On 4 Nov, 16:26, Cash Costello <cash.coste...@gmail.com> wrote:
> > 1. Passing username and password with GET is a bad idea. The password
> > will be written to your web server log.
> > 2. I recommend using the user token. You first make a call that passes
> > the username and password (using POST). You are returned a user token
> > that is good for 1 hour by default. Now in every subsequent call for
> > that user, pass the token as the parameter "auth_token".
> > 3. I plan to remove the option passing the username and password on
> > every call by default. Developers will be able to turn it on though
> > definitely not recommended.
> > 4. You also have the option of building your own user authentication
> > module. Without knowing your application I can't tell if it is a good
> > fit for you.
> > On Nov 4, 9:39 am, "Phil.T" <tran....@gmail.com> wrote:
> > > Thanks cash for the tip. I updated those files, but something make me
> > > scratch my head...
> > > I need to authenticate the user, first with simple GET (without HMAC).
> > > When I use:
> > > - expose_function(... , 'GET', false, false), user is not
> > > authenticated,
> > > - expose_function(... , 'GET', false, true), it returns an error,
> > > because user is not authenticated even with username and password
> > > parameters.
> > > But when looking at the usage of pam_auth_userpass($credentials) in
> > > api.php, it looks like it is never called with the right user/password
> > > credentials.
> > > My question is : do I need to correct this ? and initiate credentials
> > > (from $_GET or $_POST) in pam_auth_userpass(), or in the caller
> > > function ?
> > > > If you're just starting out, I recommend grabbing the latest REST api
> > > > from svn because it has a lot of bug fixes. The files you need are:
> > > > Note that api.php has a hook into Elgg's new unit testing framework
> > > > but you won't be able to use that without grabbing more files from
> > > > svn. Also, currently the schema in SVN has a bug which breaks the
> > > > activity river.
> > > > Cash
> > > > On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > > > > Hi Cash and everybody.
> > > > > to answer your survey:
The next big update is done on the web services API. Changes include
1. hmac should now be compatible with Amazone S3 and OAuth - will
probably add a nonce
2. users won't be logged out now
3. cut out the extraneous wrapper of json output
4. centralized web services handler - this is the biggest change
The rest api is now hit at /services/api/rest/xml/?method=test
You can now replace the default rest handler with your own.
You can add additional web services. ex: /services/api/soap/xml for
example
I whipped up a quick example where I registered a "web service" called
docs that provided full documentation on each registered function /
services/api/doc/?method=test
Please note that you will need to update your .htaccess file for this
to work.
Cash
On Oct 25, 4:20 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> The current Elgg REST API is not really RESTful but more of a REST/RPC
> hybrid approach (similar to Twitter, Facebook, Flickr). It is not
> structured well to handle more than GET/POST in a nontrivial fashion.
> As such, I think I'm going to stick with the current GET/POST
> restrictions. Any comments?
> On Oct 23, 8:30 am, Cash Costello <cash.coste...@gmail.com> wrote:
> > I've used php and java with the current hmac without any problems (and
> > I did not write it). I'm going to look into making it compatible with
> > OAuth:http://oauth.net/core/1.0#anchor16
> > I've add a simple api auth method that just requires the public key.
> > This is probably sufficient for using the API to integrate
> > applications and for a lot of external facing uses, too.
> > I noticed from your client that you are using more than GET and POST.
> > That's also something that I've kicked around but wasn't sure anyone
> > would use it.
> > On Oct 23, 7:15 am, milan <mi...@magudia.com> wrote:
> > > 1) Yes - I think we are, but not open sourced api's
> > > 2) Created elgg based web services
> > > 3) See 4!
> > > 4) We're using the HMAC signatures or to be accurate we tried to use
> > > them and found them to not be compatible with other tool sets and
> > > languages. The problem I think was that the HMAC was calculated into
> > > hex values and not encoded into a standard canonicalized format which
> > > doesn't change across toolkits.
> > > a) The actually format of the string to sign wasn't normalised to
> > > UTF-8 (not normally an issue, but can be)
> > > b) The hmac isn't generated using binary values (see:http://php.net/manual/en/function.hash-hmac.php)
> > > c) If the hmac is in binary then the output of this can be base64
> > > encoded into a standard strict format, which is built into nearly
> > > every language by default (apart from *cough* java where you need a
> > > external jar).
> > > Why do this? As other languages by default out put binary values from
> > > the HMAC and also the hex output is generally unpredictably different.
> > > We also did away with doing different Hashes for POST and GET.
> > > Basically we had a look at the Amz S3 model and then overloaded the
> > > current API - I think.
> > > As for 5) and 6), i'll ask Sammy as he done more API work than I have!
> > > Milan
> > > On Oct 22, 2:40 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > > > Hi, Antoine
> > > > If you're just starting out, I recommend grabbing the latest REST api
> > > > from svn because it has a lot of bug fixes. The files you need are:
> > > > Note that api.php has a hook into Elgg's new unit testing framework
> > > > but you won't be able to use that without grabbing more files from
> > > > svn. Also, currently the schema in SVN has a bug which breaks the
> > > > activity river.
> > > > Cash
> > > > On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > > > > Hi Cash and everybody.
> > > > > to answer your survey:
> The next big update is done on the web services API. Changes include
> 1. hmac should now be compatible with Amazone S3 and OAuth - will
> probably add a nonce
> 2. users won't be logged out now
> 3. cut out the extraneous wrapper of json output
> 4. centralized web services handler - this is the biggest change
> The rest api is now hit at /services/api/rest/xml/?method=test
> You can now replace the default rest handler with your own.
> You can add additional web services. ex: /services/api/soap/xml for
> example
> I whipped up a quick example where I registered a "web service" called
> docs that provided full documentation on each registered function /
> services/api/doc/?method=test
> Please note that you will need to update your .htaccess file for this
> to work.
> Cash
> On Oct 25, 4:20 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > The current Elgg REST API is not really RESTful but more of a REST/RPC
> > hybrid approach (similar to Twitter, Facebook, Flickr). It is not
> > structured well to handle more than GET/POST in a nontrivial fashion.
> > As such, I think I'm going to stick with the current GET/POST
> > restrictions. Any comments?
> > On Oct 23, 8:30 am, Cash Costello <cash.coste...@gmail.com> wrote:
> > > I've used php and java with the current hmac without any problems (and
> > > I did not write it). I'm going to look into making it compatible with
> > > OAuth:http://oauth.net/core/1.0#anchor16
> > > I've add a simple api auth method that just requires the public key.
> > > This is probably sufficient for using the API to integrate
> > > applications and for a lot of external facing uses, too.
> > > I noticed from your client that you are using more than GET and POST.
> > > That's also something that I've kicked around but wasn't sure anyone
> > > would use it.
> > > On Oct 23, 7:15 am, milan <mi...@magudia.com> wrote:
> > > > 1) Yes - I think we are, but not open sourced api's
> > > > 2) Created elgg based web services
> > > > 3) See 4!
> > > > 4) We're using the HMAC signatures or to be accurate we tried to use
> > > > them and found them to not be compatible with other tool sets and
> > > > languages. The problem I think was that the HMAC was calculated into
> > > > hex values and not encoded into a standard canonicalized format which
> > > > doesn't change across toolkits.
> > > > a) The actually format of the string to sign wasn't normalised to
> > > > UTF-8 (not normally an issue, but can be)
> > > > b) The hmac isn't generated using binary values (see:http://php.net/manual/en/function.hash-hmac.php)
> > > > c) If the hmac is in binary then the output of this can be base64
> > > > encoded into a standard strict format, which is built into nearly
> > > > every language by default (apart from *cough* java where you need a
> > > > external jar).
> > > > Why do this? As other languages by default out put binary values from
> > > > the HMAC and also the hex output is generally unpredictably different.
> > > > We also did away with doing different Hashes for POST and GET.
> > > > Basically we had a look at the Amz S3 model and then overloaded the
> > > > current API - I think.
> > > > As for 5) and 6), i'll ask Sammy as he done more API work than I have!
> > > > Milan
> > > > On Oct 22, 2:40 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > > > > Hi, Antoine
> > > > > If you're just starting out, I recommend grabbing the latest REST api
> > > > > from svn because it has a lot of bug fixes. The files you need are:
> > > > > Note that api.php has a hook into Elgg's new unit testing framework
> > > > > but you won't be able to use that without grabbing more files from
> > > > > svn. Also, currently the schema in SVN has a bug which breaks the
> > > > > activity river.
> > > > > Cash
> > > > > On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > > > > > Hi Cash and everybody.
> > > > > > to answer your survey:
> I've added a nonce to the HMAC signature. In the next week or so, I'll > try to update the documentation on the wiki on the changes to HMAC > signatures.
> Next up is allowing more flexibility in parameters for exposed methods > (probably default values).
> Cash
> On Nov 9, 9:03 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > The next big update is done on the web services API. Changes include
> > 1. hmac should now be compatible with Amazone S3 and OAuth - will > > probably add a nonce > > 2. users won't be logged out now > > 3. cut out the extraneous wrapper of json output > > 4. centralized web services handler - this is the biggest change
> > The rest api is now hit at /services/api/rest/xml/?method=test
> > You can now replace the default rest handler with your own. > > You can add additional web services. ex: /services/api/soap/xml for > > example
> > I whipped up a quick example where I registered a "web service" called > > docs that provided full documentation on each registered function / > > services/api/doc/?method=test
> > Please note that you will need to update your .htaccess file for this > > to work.
> > Cash
> > On Oct 25, 4:20 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > > The current Elgg REST API is not really RESTful but more of a REST/RPC > > > hybrid approach (similar to Twitter, Facebook, Flickr). It is not > > > structured well to handle more than GET/POST in a nontrivial fashion. > > > As such, I think I'm going to stick with the current GET/POST > > > restrictions. Any comments?
> > > On Oct 23, 8:30 am, Cash Costello <cash.coste...@gmail.com> wrote:
> > > > I've used php and java with the current hmac without any problems (and > > > > I did not write it). I'm going to look into making it compatible with > > > > OAuth:http://oauth.net/core/1.0#anchor16
> > > > I've add a simple api auth method that just requires the public key. > > > > This is probably sufficient for using the API to integrate > > > > applications and for a lot of external facing uses, too.
> > > > I noticed from your client that you are using more than GET and POST. > > > > That's also something that I've kicked around but wasn't sure anyone > > > > would use it.
> > > > On Oct 23, 7:15 am, milan <mi...@magudia.com> wrote:
> > > > > 1) Yes - I think we are, but not open sourced api's
> > > > > 2) Created elgg based web services
> > > > > 3) See 4!
> > > > > 4) We're using the HMAC signatures or to be accurate we tried to use > > > > > them and found them to not be compatible with other tool sets and > > > > > languages. The problem I think was that the HMAC was calculated into > > > > > hex values and not encoded into a standard canonicalized format which > > > > > doesn't change across toolkits.
> > > > > a) The actually format of the string to sign wasn't normalised to > > > > > UTF-8 (not normally an issue, but can be) > > > > > b) The hmac isn't generated using binary values (see:http://php.net/manual/en/function.hash-hmac.php) > > > > > c) If the hmac is in binary then the output of this can be base64 > > > > > encoded into a standard strict format, which is built into nearly > > > > > every language by default (apart from *cough* java where you need a > > > > > external jar).
> > > > > Why do this? As other languages by default out put binary values from > > > > > the HMAC and also the hex output is generally unpredictably different.
> > > > > We also did away with doing different Hashes for POST and GET. > > > > > Basically we had a look at the Amz S3 model and then overloaded the > > > > > current API - I think.
> > > > > As for 5) and 6), i'll ask Sammy as he done more API work than I have!
> > > > > Milan
> > > > > On Oct 22, 2:40 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > > > > > Hi, Antoine
> > > > > > If you're just starting out, I recommend grabbing the latest REST api > > > > > > from svn because it has a lot of bug fixes. The files you need are:
> > > > > > Note that api.php has a hook into Elgg's new unit testing framework > > > > > > but you won't be able to use that without grabbing more files from > > > > > > svn. Also, currently the schema in SVN has a bug which breaks the > > > > > > activity river.
> > > > > > Cash
> > > > > > On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > > > > > > Hi Cash and everybody. > > > > > > > to answer your survey:
> > > > > > > 1) No but it's a project
> > > > > > > 2) iPhone and adroid application
> > > > > > > 3) not yet but I will implement it
> > > > > > > 4) just setting that up right now :)- Zitierten Text ausblenden -
The documentation on the wiki hasn't been updated yet. Rather than using the page handler, the new services API uses a service handler. You will need to update your htaccess if this is not a fresh install from svn and you need to hit /services/api/rest/xml/? method=system.api.list
On Dec 23, 7:52 am, Thomas <thomas.winkelm...@gmail.com> wrote:
> I have the following problem with the the new api. When I call /pg/api/ > rest/xml/?method=system.api.list I always will be forwarded to the > Dashboard.
> I enabled REST API in Site Settings, but no effect. I habe no idea > what is wrong.
> On 12 Nov., 13:55, Cash Costello <cash.coste...@gmail.com> wrote:
> > I've added a nonce to the HMAC signature. In the next week or so, I'll > > try to update the documentation on the wiki on the changes to HMAC > > signatures.
> > Next up is allowing more flexibility in parameters for exposed methods > > (probably default values).
> > Cash
> > On Nov 9, 9:03 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > > The next big update is done on the web services API. Changes include
> > > 1. hmac should now be compatible with Amazone S3 and OAuth - will > > > probably add a nonce > > > 2. users won't be logged out now > > > 3. cut out the extraneous wrapper of json output > > > 4. centralized web services handler - this is the biggest change
> > > The rest api is now hit at /services/api/rest/xml/?method=test
> > > You can now replace the default rest handler with your own. > > > You can add additional web services. ex: /services/api/soap/xml for > > > example
> > > I whipped up a quick example where I registered a "web service" called > > > docs that provided full documentation on each registered function / > > > services/api/doc/?method=test
> > > Please note that you will need to update your .htaccess file for this > > > to work.
> > > Cash
> > > On Oct 25, 4:20 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > > > The current Elgg REST API is not really RESTful but more of a REST/RPC > > > > hybrid approach (similar to Twitter, Facebook, Flickr). It is not > > > > structured well to handle more than GET/POST in a nontrivial fashion. > > > > As such, I think I'm going to stick with the current GET/POST > > > > restrictions. Any comments?
> > > > On Oct 23, 8:30 am, Cash Costello <cash.coste...@gmail.com> wrote:
> > > > > I've used php and java with the current hmac without any problems (and > > > > > I did not write it). I'm going to look into making it compatible with > > > > > OAuth:http://oauth.net/core/1.0#anchor16
> > > > > I've add a simple api auth method that just requires the public key. > > > > > This is probably sufficient for using the API to integrate > > > > > applications and for a lot of external facing uses, too.
> > > > > I noticed from your client that you are using more than GET and POST. > > > > > That's also something that I've kicked around but wasn't sure anyone > > > > > would use it.
> > > > > On Oct 23, 7:15 am, milan <mi...@magudia.com> wrote:
> > > > > > 1) Yes - I think we are, but not open sourced api's
> > > > > > 2) Created elgg based web services
> > > > > > 3) See 4!
> > > > > > 4) We're using the HMAC signatures or to be accurate we tried to use > > > > > > them and found them to not be compatible with other tool sets and > > > > > > languages. The problem I think was that the HMAC was calculated into > > > > > > hex values and not encoded into a standard canonicalized format which > > > > > > doesn't change across toolkits.
> > > > > > a) The actually format of the string to sign wasn't normalised to > > > > > > UTF-8 (not normally an issue, but can be) > > > > > > b) The hmac isn't generated using binary values (see:http://php.net/manual/en/function.hash-hmac.php) > > > > > > c) If the hmac is in binary then the output of this can be base64 > > > > > > encoded into a standard strict format, which is built into nearly > > > > > > every language by default (apart from *cough* java where you need a > > > > > > external jar).
> > > > > > Why do this? As other languages by default out put binary values from > > > > > > the HMAC and also the hex output is generally unpredictably different.
> > > > > > We also did away with doing different Hashes for POST and GET. > > > > > > Basically we had a look at the Amz S3 model and then overloaded the > > > > > > current API - I think.
> > > > > > As for 5) and 6), i'll ask Sammy as he done more API work than I have!
> > > > > > Milan
> > > > > > On Oct 22, 2:40 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > > > > > > Hi, Antoine
> > > > > > > If you're just starting out, I recommend grabbing the latest REST api > > > > > > > from svn because it has a lot of bug fixes. The files you need are:
> > > > > > > Note that api.php has a hook into Elgg's new unit testing framework > > > > > > > but you won't be able to use that without grabbing more files from > > > > > > > svn. Also, currently the schema in SVN has a bug which breaks the > > > > > > > activity river.
> > > > > > > Cash
> > > > > > > On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > > > > > > > Hi Cash and everybody. > > > > > > > > to answer your survey:
> > > > > > > > 1) No but it's a project
> > > > > > > > 2) iPhone and adroid application
> > > > > > > > 3) not yet but I will implement it
> > > > > > > > 4) just setting that up right now :)- Zitierten Text ausblenden -
> The documentation on the wiki hasn't been updated yet. Rather than > using the page handler, the new services API uses a service handler. > You will need to update your htaccess if this is not a fresh install > from svn and you need to hit /services/api/rest/xml/? > method=system.api.list
> On Dec 23, 7:52 am, Thomas <thomas.winkelm...@gmail.com> wrote:
> > Hi,
> > I have the following problem with the the new api. When I call /pg/api/ > > rest/xml/?method=system.api.list I always will be forwarded to the > > Dashboard.
> > I enabled REST API in Site Settings, but no effect. I habe no idea > > what is wrong.
> > On 12 Nov., 13:55, Cash Costello <cash.coste...@gmail.com> wrote:
> > > I've added a nonce to the HMAC signature. In the next week or so, I'll > > > try to update the documentation on the wiki on the changes to HMAC > > > signatures.
> > > Next up is allowing more flexibility in parameters for exposed methods > > > (probably default values).
> > > Cash
> > > On Nov 9, 9:03 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > > > The next big update is done on the web services API. Changes include
> > > > 1. hmac should now be compatible with Amazone S3 and OAuth - will > > > > probably add a nonce > > > > 2. users won't be logged out now > > > > 3. cut out the extraneous wrapper of json output > > > > 4. centralized web services handler - this is the biggest change
> > > > The rest api is now hit at /services/api/rest/xml/?method=test
> > > > You can now replace the default rest handler with your own. > > > > You can add additional web services. ex: /services/api/soap/xml for > > > > example
> > > > I whipped up a quick example where I registered a "web service" called > > > > docs that provided full documentation on each registered function / > > > > services/api/doc/?method=test
> > > > Please note that you will need to update your .htaccess file for this > > > > to work.
> > > > Cash
> > > > On Oct 25, 4:20 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > > > > The current Elgg REST API is not really RESTful but more of a REST/RPC > > > > > hybrid approach (similar to Twitter, Facebook, Flickr). It is not > > > > > structured well to handle more than GET/POST in a nontrivial fashion. > > > > > As such, I think I'm going to stick with the current GET/POST > > > > > restrictions. Any comments?
> > > > > On Oct 23, 8:30 am, Cash Costello <cash.coste...@gmail.com> wrote:
> > > > > > I've used php and java with the current hmac without any problems (and > > > > > > I did not write it). I'm going to look into making it compatible with > > > > > > OAuth:http://oauth.net/core/1.0#anchor16
> > > > > > I've add a simple api auth method that just requires the public key. > > > > > > This is probably sufficient for using the API to integrate > > > > > > applications and for a lot of external facing uses, too.
> > > > > > I noticed from your client that you are using more than GET and POST. > > > > > > That's also something that I've kicked around but wasn't sure anyone > > > > > > would use it.
> > > > > > On Oct 23, 7:15 am, milan <mi...@magudia.com> wrote:
> > > > > > > 1) Yes - I think we are, but not open sourced api's
> > > > > > > 2) Created elgg based web services
> > > > > > > 3) See 4!
> > > > > > > 4) We're using the HMAC signatures or to be accurate we tried to use > > > > > > > them and found them to not be compatible with other tool sets and > > > > > > > languages. The problem I think was that the HMAC was calculated into > > > > > > > hex values and not encoded into a standard canonicalized format which > > > > > > > doesn't change across toolkits.
> > > > > > > a) The actually format of the string to sign wasn't normalised to > > > > > > > UTF-8 (not normally an issue, but can be) > > > > > > > b) The hmac isn't generated using binary values (see:http://php.net/manual/en/function.hash-hmac.php) > > > > > > > c) If the hmac is in binary then the output of this can be base64 > > > > > > > encoded into a standard strict format, which is built into nearly > > > > > > > every language by default (apart from *cough* java where you need a > > > > > > > external jar).
> > > > > > > Why do this? As other languages by default out put binary values from > > > > > > > the HMAC and also the hex output is generally unpredictably different.
> > > > > > > We also did away with doing different Hashes for POST and GET. > > > > > > > Basically we had a look at the Amz S3 model and then overloaded the > > > > > > > current API - I think.
> > > > > > > As for 5) and 6), i'll ask Sammy as he done more API work than I have!
> > > > > > > Milan
> > > > > > > On Oct 22, 2:40 pm, Cash Costello <cash.coste...@gmail.com> wrote:
> > > > > > > > Hi, Antoine
> > > > > > > > If you're just starting out, I recommend grabbing the latest REST api > > > > > > > > from svn because it has a lot of bug fixes. The files you need are:
> > > > > > > > Note that api.php has a hook into Elgg's new unit testing framework > > > > > > > > but you won't be able to use that without grabbing more files from > > > > > > > > svn. Also, currently the schema in SVN has a bug which breaks the > > > > > > > > activity river.
> > > > > > > > Cash
> > > > > > > > On Oct 22, 5:49 am, Ant- <antoine.raba...@gmail.com> wrote:
> > > > > > > > > Hi Cash and everybody. > > > > > > > > > to answer your survey:
