login page if not authorized

Justin Sheehy justin at iago.org
Mon Aug 10 11:32:54 EDT 2009

Hi Pablo,

On Mon, Aug 10, 2009 at 10:52 AM, pablo platt<pablo.platt at gmail.com> wrote:

> What confuse me is that some functions return the response as the first term like
>>               to_json(RequestData, Context) ->
> but some functions return boolean and should modify the RequestData like
>>               process_post(RD, Ctx) ->
> Can you please explain why to_json returns the response but process_post
> returns true and have to modify ReuqestData?

This is because Webmachine's interfaces are driven by the HTTP specification.

A resource's provided representation, as must be produced in response
to a GET request, is returned by the content-providing functions such
as to_json.  In contrast, there is no formally specified body in the
response to a POST request and so there is no assumption that
processing a POST request will produce any body at all.

> Another thing that confuse me is that RequestData. The name implies that
> it's the request but process_post modify it
> to change the response. What is ReuqestData and what it contains?

RequestData represents the currently-being-processed HTTP request,
including any accumulated data that will be used in the (not yet sent
and thus technically not yet existing) response.  We could have broken
the response-specific data out, but it wouldn't have provided any
obvious benefit save for making you carry around another variable.

> Can I change headers and redirect in any step and in any function?
> How do I do that?

You can change headers in any function by modifying the ReqData and
providing the modified copy in the response from that function.

If by "redirect" you mean exit from the decision process with a
specific status code, you should look at the docs.  The HALT column on
http://bitbucket.org/justin/webmachine/wiki/WebmachineResources shows
you exactly which functions can do this.

>> > I can check in every resource if the user is authenticated by matching a
>> > session cookie to a session table.
>> Yes, you can.  It's important to realize that this is in conflict with
>> REST.  That is not to say that you should not do it, just to say that
>> Webmachine tries to shape things in a RESTful manner, so you won't
>> find as much built-in utility for dealing with things that are not in
>> that mode.
> Why is that in conflict with REST?

One of the core principles of REST is that it explicitly constrains
application state (not resource state) to be held on the client.  The
"session table" you refer to is application state (as it is not named
by a URI, it could not be resource state) and is held on the server.

>> For HTTP Authentication, you'll find wrq:get_req_header/2 and
>> base64:mime_decode_to_string/1 useful.
> Do I need to base64 decode  if the url is a simple string?
> I saw an example that uses base64 and I didn't understand why

HTTP Authentication is explicitly defined in the RFC as using base64 encoding.


More information about the webmachine mailing list