I hope this is the right place to post this, apologies if it isn't.
I have been working a bit with ActiveResource for an application I'm
building at work. Ares is fantastic (as is Rails 1.2, great job guys),
but I have run into a small issue.
All applications at my company sit behind a secure reverse proxy (IBM
Tivoli Access Manager WebSEAL). It's configured in such a way that only
forms-based authentication is allowed. Applications behind the proxy
receive the user credential in the header, and then make a web service
call to retrieve user meta data and finer-grained access roles. The
rails app has a session, as does the reverse proxy. In order to make
ActiveResource work I need a way to pass in those session cookies so it
will send them when it makes requests. I can write the forms-based
login bits myself and retrieve the cookies (I already have in fact).
But Ares doesn't (appear to) have a way to pass in arbitrary headers.
My first question is, is there a way to do this that I missed? What I
ended up doing was modifying the code to allow passing a cookie string
which gets added to the default_headers. It works perfectly, and I'll
happily send a patch. But I wonder if there might be some value in
allowing more broad access to the Net::HTTP connection options in
general?
Forgive me if there already is a way to do this. But if there currently
isn't, is this something that could be added? I'd be willing to hack at
it if requested.
Forgive me if there already is a way to do this. But if there currently
isn't, is this something that could be added? I'd be willing to hack at
it if requested.
I like the idea of being able to set custom headers in a friendly way.
I would, however, see if your application couldn't be made to work with
both a session based login system and HTTP auth/digest. The latter is a
better fit for REST-based authentication and should be able to happily
coexist with session-based authentication (the current application I'm
working on supports both).
I would, however, see if your application couldn't be made to work with
both a session based login system and HTTP auth/digest. The latter is a
better fit for REST-based authentication and should be able to happily
coexist with session-based authentication (the current application I'm
working on supports both).
That was my thought too, and I tried it. But since we're using a
commercial reverse proxy I don't have the kind of flexibility I'd like.
It's an all or nothing choice for basic auth or forms. I can use certs,
or ip based restriction though. But for simplicities sake I decided on
username/password (which must be forms based) for the interactive
services. For automated things I'll use ssl certs. The service in
question is currently managed in a flat file on a unix server, and I'm
moving the data to the new application. But they want to be able to
work with the data from the command line still, and there are several
users, each with different access levels. So it seemed easiest to just
have them login using their proxy ids and do it that way. Ideally
they'd just use the web interface, but alas...
I like the idea of being able to set custom headers in a friendly way.
Is this something you'll do or should I try it and submit a patch?
Oh, one other thing. In my case there's another problem with BA. Logins
are expensive since the backend app doesn't know anything about the
user. The app receives the identity from the reverse proxy, then calls
an infrastructure web service (unrelated to rails) to get the user meta
data and roles. That takes a second or so, so if even if BA would work
it would be a lot slower since that would happen on each request. With
cookies it would only have to happen once.
This is an edge case of course, which is why I suggested having a way
to pass in headers and would handle the details on my own.