Forum: Ruby on Rails ActiveResource authorization

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
on 2007-06-26 02:13
(Received via mailing list)
Hi all!

I have been using AR to access a restful API. Users are authorized
over http to get information that is restricted. Everything has been
working until I realized that the request to the API must be a valid
URL. This means that users with username:password that contains
characters that will create an invalid URL cannot access their

Has anyone run into this problem and found a solution?

I guess sending the login info in the request header means that I can
stay with allowing all types of characters in usernames and passwords.
But then I will have to make changes to ActiveResource which I am not
completely comfortable with.

ara_vartanian (Guest)
on 2007-06-27 07:04
(Received via mailing list)
Yes, I have.

I think it limits adoption of ActiveResource because one common REST
implementation style would be e-mail address as username, which is
easy to handle in HTTP Basic, but not when it is included in the URL,
since the '@' automatically invalidates it as a URL.

You could probably URL encode the invalid characters before slipping
them into the URL, but AR then would mess up the HTTP Basic request
header it also adds, including the unnecessary encoding.

I think what would be sensible would be a class method on
ActiveResource::Base like the site method that allows you to set the
HTTP Basic request header directly, bypassing the inclusion in the
URL. That way, AR would work with a lot more APIs.

On Jun 25, 9:52 am, "removed_email_address@domain.invalid" 
ara_vartanian (Guest)
on 2007-06-27 07:48
(Received via mailing list)
What's more, the AR source makes this difficult to patch, since the
various classes only pass around a URI object as the sole piece of
configuration. That way, no way to express request headers that are a
standard contraption in lots of REST APIs.
This topic is locked and can not be replied to.