Re: [rest-discuss] uFormats applied to the URI... Mea Culpa
- So... I posted to the wrong list. I really wanted to post my idea to
the uf-rest (microformats rest) mailinglist, and then bring the results
over here for further discussion.
Sorry about that folks.
On the other hand, I have learned a good deal from the ensuing
discussion, and would like to thank everyone again.
http://microformats.org/about/ tells you all about what microformats
are, in cause you were wondering.
Again, I apologize.
- Hi Jonathan,
> Really, I wonder if you can meet your needs with REST at all. See,In my scheme the only state stored on the server, and replicated
> clincher for me is the timing out of user logins, because you need to
> store the state of the user somewhere on the server to know when to
> them out. Perhaps my method (storing the session as a resource) is
> RESTfully not REST :P ? At least this way the client has some kind of
> control over the session, and the session isn't interfering with the
among all the servers, is a pair of passwords used to encrypt the
cookies. These passwords expire every 30 minutes, and I keep two
around (so I replicate a new one every 15 minutes). I'm planning on
keeping a cache of roles and permissions for users once they log in,
which can be accessed by the session id. I'll use sticky sessions so
requests to that site always go back to the server where the cache
is. It is just a cache, though. It will go into the cache with a
timeout, and can be evicted early if memory gets full. If that
happens, or a server crashes, or someone clicks over to a URL at a
different site in the network served up by a different server, and a
request comes in with a session ID that doesn't reference anything in
the roles/permissions cache, I just use the password to decrypt the
session ID and reauthenticate the user.
I don't think there's really any "state of the user somewhere on the
server," at least nothing that can't be uniquely referenced with a
URI. (All theory. I haven't implemented it yet.)
> the issues with Iframes?
By the way, I think I came up with another way to log people off of
some kind of password that no one can have. For example, if you
require that passwords are at least six chars long, then no one can
have the password "abc". When you want to log someone out (because
the client can run and do an HTTP authentication for the realm you
want to log the user out of at a special URI with the user's username
and the password "abc". This authentication will succeed at that
special URI, which now means that the next time someone goes to any
other URI in that realm at that site from that client, it will
attempt to authenticate with the wrong password. You have effectively
logged the user out of his or her auth session for that realm.
> Bill Venners wrote:
>> I had to think about this idea for a bit, and am still not quite
>> sure I
>> understand it fully. One problem I believe I see is that it doesn't
>> provide the server with a sure-fire way to recognize the client,
>> so it
>> won't always know for which realm to prompt authentication. I.e.,
>> if you
>> use a different realm string for each session, then the server
>> needs to
>> know what realm string to prompt for in its 401 response on a
>> Once authenticated, the client may preemptively send the
>> header, but the realm is buried inside the digest-response, and
>> the client may not send it until getting a 401. But before the server
>> sends the 401, it needs to know the realm. So really I think the
>> needs to something the server can determine from the request URI.
>> The other concern is that a URL like this:
>> seems to indicate I've created state on the server for the auth
>> which is something I'd rather avoid. I would prefer the auth state
>> to be
>> on the client, so when a user creates an auth session, that state
>> is on
>> the client for the duration of the session, after which it gets
>> On each request during the auth session, the auth state goes from
>> to the server. This my current best understanding of what REST says
>> about authentication. (Even though you've taken the innovative
>> step of
>> giving the session a URI on the server, it still feels to me like
>> in the wrong place there on the server.)
>> My understanding of why REST suggests we avoid session state (almost
>> every web framework makes using session state easy), is that extra-
>> state breaks caching and hinders scalability. There are good
>> answers to
>> scalability with session state too, such as cache coherence tools and
>> several other techniques, but I really don't think it would be
>> harder to
>> build a RESTful HTTP app then a stateful one if you just keep REST in
>> mind as you go.
>> dissertation. My guess is that his main concern was that in practice
>> session cookies are used not just for auth, usually, but to point to
>> session state on the server. The cookies I've been considering
>> using in
>> our new architecture are really auth tokens. They will essentially
>> contain the username and password hash encrypted with a password that
>> all the servers will share for a half hour, after which they'll all
>> forget it. So if you bring a server up cold, and it gets one of these
>> cookies within the half-hour timeout, it can figure out who you
>> are and
>> authenticate you (with the caveat that the session cookie can be
>> hijacked). In this approach once the server sends back this
>> cookie, it
>> really represents the authentication state sitting there in the
>> and it gets sent up to the server with each request. The server can
>> forget all about the authentication, so long as it remembers the
>> half-hour passwords used to encrypt the cookies.
>>> As for sending out personalized content... what about an iframe?
>>> Enclose all personalizable content inside of an iframe, and make a
>>> secondary request for that personalized content. This helps to
>>> worms mind
>> either, to assemble the personalized representation on the client.
>> I see
>> how that would reduce server load and bandwidth, but in exchange for
>> that cost savings, I'd have the expense of testing a lot more
>> in a lot more places. I expect I'll just send out personalized
>> representations of resources, each with their own ETag.
> Yahoo! Groups Links