I'm working with the REST action/controller to expose my app to browsers
and to any remote client (json/xml, etc). For the browser stuff, I just
use the regular Auth plugins with a database store tied to a user/pass
login form. For remote clients, I wanted to tack on HTTP Auth using
Basic/Digest.

Lucky for me, we have C::P::A::Credential::HTTP, which can consume and
create the proper Basic/Digest auth headers.

Unfortunately, when this credential class creates the appropriate 401
response code and headers when auth is required, it assumes that the
content-type is text/html, and the body() needs to contain text
("Authorization Required").

IMHO, this is bad. I don't believe the it's the responsibility of this
credential to set/assume the content-type/body for me, but only to
manage reading/writing the auth headers.

Under normal operation, the REST controller receives a request for a
certain content-type, and if I set the status code myself to 401 and
detach, the outbound response is automatically set to that requested
content-type with an empty serialized entity (empty YAML, null in JSON, etc)

Since the HTTP auth credential assumes is needs to set content-type and
body(), those trash what the REST controller is doing during
serialization of the response. When it does that, response to clients
that have requested yaml/json now get tesr/html and a body they can't
consume.

It mentioned in the HTTP Auth pod that one could override these in
end(), but that means that I have to spend time in my end() sub
reimplementing logic that is already handled by the REST controller,
just to get the content-type/body back to the proper output.

At this point, I just wanted to get the conversation started on what
every thinks the correct behavior is, and if there are any work around
for this type of problem.

-=Chris


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/

Reply via email to