First, an absolutely fabulous module. I had my shortening site up and running in about an hour. Simple, and it just WORKS! You rock!
I would like to offer site users the ability to add an api key to their REST urls, but I'm not finding how or where the key is generated. Have tried different permissions with shurly_service (not really sure what it does), but nothing happens at shurly/api/key. Haven't looked at the views yet.
So, how do I set up for keys to be generated, where do I (or my users) find the key, and is it something I could expose in a block with views? Also, what does the administer shurly_service permission do?
Hope I'm not asking anything that I should have found in the documentation, if so, feel free to tell me to just go re-read it. But that's another matter, altogether. ;)

Comments

jjeff’s picture

jjeff commented

Thanks for the appreciation!

You'll need to enable the Shurly Service module and then enable the Shurly API key block. You'll probably want to restrict that block to just "user/*" pages.

It's a little awkward right now, but eventually, I'd like to work the API key into the user/{uid}/edit form.

In the meantime, you can see it "in action" by creating an account for yourself on http://lb.cm and going to your account page. Documentation (in the form of examples) for the webservices can be found here: http://github.com/Lullabot/shurly/tree/master/shurly_service/

There's a Safari extension which works with any Shurly site and uses the service to do it's thing.

bendodd’s picture

bendodd commented

Is there any sense in leveraging the Service module's API key interface?

jjeff’s picture

jjeff commented

I did look into Services module. But at the time (2 months ago) it didn't seem flexible enough. I needed GET-based access to a tiny slice of Drupal functionality using an API key without needing a session cookie. Perhaps I wasn't fully groking the capabilities of Services module, but the functionality I was looking for was pretty simple to code myself.

I'd certainly be open to Services integration if someone wants to head up that effort.

jjeff’s picture

jjeff commented

Also, as I understood, Services provides API keys to applications and not to users. So this idea of having an API key per user was not something it did. Services 3 is supposed to be more flexible. Haven't looked into it yet though.

bendodd’s picture

bendodd commented

Thanks for that JJeff, I guess what confused me was that in our case we don't want keys to be applied to users, but to 3rd-party applications, which would be more how Services would work. Using Services would also allow different servers to be used (SOAP/REST/XMLRPC etc)? Although, the overhead of using the Services API keys could be prohibitive...

Either way, the module you created is excellent.

jjeff’s picture

jjeff commented

I was basically mirroring the way that Bit.ly and several other sites do API keys where each user gets one key and they can change it if they're not happy with the way it's being used. It's not nearly as flexible as an OAuth-style system with a separately disable-able entry for each authorized application.

I'm all for Services 3 integration with ShURLy. But I'll be honest with you, I've had several failed attempts at getting my head around Services and I want to be sure that we don't sacrifice the simplicity of ShURLy's current system for the elusive flexibility of Services.

Ultimately, it would be great if you could *either* enable ShURLy's built-in services module OR enable another as-of-yet-unwritten module which would add Services integration with ShURLy. In retrospect, I probably should have called shurly_services.module something else. Oh well. :-)

uptil4music’s picture

uptil4music commented

Just a follow-up and FYI to anyone interested, the parameter ordering of the API calls IS order independent. So, for my use case I am using Shorten to provide custom Shurly URLs for all pages on the parent company website like so:
http://shorten.site/shurly/api/shorten?apiKey=84a...46_A&longUrl=

In the Shurly documentation, it shows the API key at the end, but that won't work with Shorten. Shorten appends the current page to the end of the string when making the call, so order independence for the parameters was a necessity and, I'm glad to say, present in Shurly.

This is set up as a Custom JSON service in Shorten on the parent site using an API key from an unrestricted user on the Shurly site, and the results are shown in a block on the parent site. Now every page on the parent site has a branded short URL. Shurly plus Shorten rocks!

jibus’s picture

jibus commented
Issue summary: View changes
Status: Active » Closed (fixed)

Closing issue