When I set up aso.is, I created a specific role account for creating short urls (staff members only). This is separate from Authenticated Users so we could maintain the flexibility of opening access to trusted, non-staff users later.

The staff group has full permissions (administer short urls, create, delete, view own urls, etc). Anonymous user and authenticated user have no permissions. I created a user, added that user account to the staff role group, and generated an API key for twitterfeed.com. We then created some test posts on a forum to see if twitter feed properly ran the URL through ShURLy and posted to twitter as a shorturl.

Expected behavior: a URL in the format http://aso.is/shurly/api/shorten?longUrl=%@&apiKey=[API KEY]&format=txt should cause the twitterfeed service to replace %@ with the long URL, pass it to ShURLy which will *use the API key as authentication*, create the short URL under that user account, and pass it back in plain text to twitterfeed for posting.

Actual behavior: it was unable to post and auto-create a short URL until we also granted "Create short URLs" permissions to Anonymous User in Drupal. Only then, it would create the short URL and assign it to the user account associated with the API key.

I don't want Anonymous users access to create short URLs though, as this is a branded, internal service that is not open to the public. Is this the intended behavior, or is there a way to provide access via API key without granting Create Short URLs to Anonymous user?

Comments

andrewboring’s picture

andrewboring commented
Category: support » feature

I'm changing this from "support request" to "feature request". After some additional testing, it has become obvious that this module was not designed for user-based or role-based access. One can disable the anonymous access to prevent unauthorized usage, but that disables the API access as well.

It seems that API access is always considered anonymous, rather than authenticated through the API key. There isn't much point in having user-based API keys if one can't restrict access by user.

Recommendation: if Create Short URL *must* be given to anonymous to allow API access, then an additional permission to require an API key should be added. If the short URL API call isn't accompanied by an API key, then it returns an error instead of a shorturl.

faunt’s picture

faunt commented

Any developments on this, Andrew?

Noticed aso.is is currently not public and probably in use. Were you able to come up with a workaround? or an alternate configuration?

Any guidance appreciated. Thanks, David.

faunt’s picture

faunt commented

Suggested workaround:

  1. grant Anonymous users “Create short URLs” permission
  2. add user log-in check (<?php if ($user->uid) : ?>) to page template around <?php print render($page['content']); ?> or whatever page region you’re using to print render shurly short URL form

So, in my build, where I have set /shurly to be the frontpage — for ease of use among authenticated users — I end up with:

<?php if ($user->uid) : ?>
  <?php print render($page['content']); ?>
<?php endif; ?>

Doesn’t this resolve the security threat issue? Am I missing something?

Additional notes:

  • syntax of Shurly API endpoint should be of this form: http://myshort.url/shurly/api/shorten?apiKey=[API STRING]&longUrl= (at least when integrating with Shorten URL module; haven’t tried twitterfeed)
  • I also added some header blocks to appear only for Anonymous users explaining the closed service, which won’t get in the way of power users who are logging in to access the shortening service on a daily basis.
benlotter’s picture

benlotter commented
Version: 6.x-1.0-rc2 » 7.x-1.0-beta2

I just installed the latest build of ShURLy and it still has this issue. I've got the API key working but only when I enabled anonymous to create URLs. Is there a workaround to hack the module itself?

benlotter’s picture

benlotter commented

SOLVED.

I was able to hack the module successfully to prevent anonymous use without the proper key. I changed the code in 2 places but it was the same change.

Edit /sites/all/modules/shurly/shurly_service/shurly_service.inc lines 18 and 53 (of version 7.x-1.0-beta2)
change the NULL to 'invalid' so the entire line looks like this:

    'apiKey' => 'invalid',

Basically, this forces it to lookup a UserID / APIKey pair and since "invalid" isn't there, it returns an error. I did it in both places to ensure that the shorten and expand functions are restricted to only those who have the APIKey that I generated.

If anyone needs more details, don't hesitate to ask me, but I'm not a code expert.

benlotter’s picture

benlotter commented

As it turns out with the solution in #5, the form at /shurly is still submitable for anonymous users. One more hack and I solved this issue, so this solution and #5 together will prevent all anonymous use of the shortener.

In shurly.module change line 67 access arguments for /shurly path to Administer short URLs.
In reality I just commented out the line and pasted in the line from the /admin/config/system/shurly to ensure no one but me can use the form. I want the form still open for the times I want to create a custom URL.

Here's my code:

 $items['shurly'] = array(
    'title' => 'Create URL',
    'description' => 'Create a short URL',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('shurly_create_form'),
    //'access arguments' => array('Create short URLs via form'),
    'access arguments' => array('Administer short URLs'),
  );

I'm more than happy to have someone actually fix this, but I don't have the time to learn PHP right now. I know just enough to be dangerous ;)

quicksketch’s picture

quicksketch
he/him
commented
Category: feature » bug
Status: Active » Fixed

Hi guys, I'd actually consider this a bug. I didn't see this issue until after I had corrected it, but it has been fixed in Git with these commits:

6.x: http://drupalcode.org/project/shurly.git/commitdiff/0df0d2d6276d0af53146...
7.x: http://drupalcode.org/project/shurly.git/commitdiff/199940e2f90ace576679...

Thanks for the report!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.