0 users online. Create an account or sign in to join them.Users

Search

A new extension, "REST API" is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Very nice!

Will give this a go in the next few days (need to share information between installs, this sounds like the best way to do so).

Nick: Thanks a lot!

Nick, regarding the CSV things, can't you use the default php functions for this?

Especially this seems to be exactly what you'd need.

Time to build that Cocoa framework/app.

Nick, you're the man!

[tonyarnold] Time to build that Cocoa framework/app.

What data format would it prefer? XML?

[creativedutchmen] can't you use the default php functions for this

Yep that's a start... but as we've found with other CSV extensions, fields don't always boil down to a single cell value very well. I'll see how the other guys have implemented it. Thanks :-)

What data format would it prefer? XML?

I'm not fussy — there's support for XML baked into Foundation, but the JSON API is just as appealing given Lion's impending arrival.

I'll probably prototype using XML.

I just added CSV export. It's not as clean as the others since it needs to inspect the data to decide what to use as the cell value (e.g. File Upload fields return the file name) but it should work for the majority of cases.

Edit: I've rolled CSV support back. It works for the Entries plugin, but not for anything else. It's just not generic enough, so will leave it commented out for now. If there's significant demand then I'll add it back. It may be that each plugin has to say which output formats it can support.

I'll probably prototype using XML.

Great, can't wait to see what you come up with!

tonyarnold: make it a POSIX compatible CLI tool with a Cocoa GUI. :-)

Yeaaah! Thank you Nick :)

Nick this seems to work awesome. When I 'have the cookie' (because I'm logged in in the Symphony site running the API) I can access my entries fine: http://site.dev/symphony/api/entries/countries

However, I wanted to use the 'token' solution to authentication so I enabled the remote login for my username on the 'API site' and tried accessing the url http://site.dev/symphony/api/entries/countries?token=:token

At first I simply got a 'no results' error on my other Symphony site. Later (after fiddling with remote logins there etc) I got the following error in my 'response' XML:

<response>
    <error>array_key_exists() [<a href='function.array-key-exists'>function.array-key-exists</a>]: The second argument should be either an array or an object</error>
</response>

I'm not sure how the remote-login is supposed to work (I have identical users on both sites) and I'm not sure this is a bug or just me configuring the DS wrongly. (I had also upped my Dynamic DS's caching). Any ideas?

PS: thanks so much for all your work and swift replies.

You shouldn't need to worry about users on the local site. The token is a unique has given to an author login, so you just need the token of the author on the master site and pass that in the URL. It logs the user in for that request only, logging them out afterwards.

So to confirm, if you log out of Symphony and then go to this URL without the token, you should be denied. Add the token, you should see your entries.

http://site.dev/symphony/api/entries/countries?token=:token

The exact same URL should then work as the URL of a dynamic XML data source. I'm not sure what the array_keys_exists error is, but maybe it's to do with the same user existing on both sites. You might be best creating an "API" author on the master site and using its token, keeping it separate from normal Symphony author accounts.

You can verify the authentication working by pulling up a console window and trying:

curl http://site.dev/symphony/api/entries/countries

And then:

curl http://site.dev/symphony/api/entries/countries?token=:token

However, I wanted to use the 'token' solution to authentication so I enabled the remote login for my username on the 'API site' and tried accessing the url http://site.dev/symphony/api/entries/countries?token=:token

The token-parameter is not tokenbut auth-token.

http://site.dev/symphony/api/entries/countries?auth-token=:token

should work.

In the REST API extension I look for token and not auth-token, so in this case it should be token. Do you think I should use auth-token for consistency instead?

Just looked at your code and saw that you're using token :-) And yep, I think auth-token is better. Just for the consistency.

Nick, I understand. The authentication part seems to work since I am disallowed when logged out, and allowed when logged in (not using a token). However, using the token I still receive the array_keys_exists error (I created a new 'Api User' so it does not seem to relate to the identical user accounts).

Somewhere in the process of building the XML this array_key_exists error is triggered because the second argument is no array/object.

The only places I can find that use array_key_exist() are (Symphony!) class.cookie.php:148 and class.extensionmanager.php:170 and some in class.lang.php (is $language an object/array?)

UPDATE woah: I just tried with auth-token and it works! This is very strange because I see you are explicitly checking for $_REQUEST['token']

I check using curl to make sure there were no cookie-issues.

curl http://site.dev/symphony/api/entries/countries?token=:token gives the error but curl http://site.dev/symphony/api/entries/countries?auth-token=:token works... wut?

Probably a stupid question:

The REST API seems perfect for building an ajax-powered site, but that would expose the auth-token through publicly available JS-files. This would be a bad idea, right?

You ould use a proxy php file to hide the token in and ajax your requests to that.

Nick said to me the other day on Twitter that to create a publicly accessible REST API for putting comments into the system via Ajax, it could be done easily with DSs Pages outputting XML and Events, rather than use this authorised user one.

but that would expose the auth-token through publicly available JS-files. This would be a bad idea, right?

Yes! Don't use this publicly. Anyone can change the URL and access whatever section they wish. For frontend AJAX, use normal pages and events in the normal way.

nick, any ideas on the token vs auth-token issue? It seems like something should probably be either documented or fixed, no?

I still don't see how this works since I can only see you checking for $_REQUEST['token']. Strange…

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details