Oops, I should not have brought up the s-word. That was terminology from the Core J2EE Patterns text. Instead, I have no intention to introduce any sort of session state because I want my service to work with sessionless command-line clients.
What I really meant is putting some kind of application-specific Remote Façade on top of the less application-specific but still data-model-specific repository because I don't want to push this functionality into the repository itself.
In response to your earlier message, @Chris, for now I have rewritten the resource behavior to interact with the repository as late and as few times as semantically possible. Keep in mind that this behavior and the underlying use case are taken straight from the Restlet implementation of the example in the Richardson & Ruby book. Now, as @n8han observed, for each request there are at most two (different) interactions with the repo: one for authentication (if required) and one for accessing or modifying something.
Furthermore, I understand this example a use case against the usual container-managed authentication based solely on URL pattern and request method: Some of the behavior depends on whether the request already includes authentication, and some of it depends on whether a resource already exists (e.g. unauthenticated user creation versus authenticated user update). Scalability does seem to be an issue, and it might be nice somehow to separate out the authentication concern (I am avoiding the a-word here
).
Btw, I am now using for-comprehensions almost everywhere. Exceptions are used only for real error situations such as a bad request.
chris_lewis wrote
At least that solution would avoid the performance issue. With something like a façade to something like a session-backed cache, the hit would be less severe, but personally I would choose to avoid it all together.
As for a "good" solution: an explicit service call works, be it an explicit dependency or something mixed in from a trait. However I feel like there is a better solution. The nice thing about a typical webapp is that authorization is safely tucked out of sight, and its results are persistent (ie a User object is on the session). I say "nice" because one needn't fiddle about with repetitious service calls.
There have been other chats about user authentication in unfiltered, and it seems the general consensus is to have a dedicated authorization trait that runs early. This frees you from validation later, but is of no help if you need a User instance. So I have two suggestions:
1) A session extractor. Auth traits could use the session and extractor without the worry of a double service hit.
2) A kind of request attribute extension to unfiltered, which would probably be analogous to servlet request attributes. Such attributes would be available for the duration of the request, and be available for access/addition to intents. I've not gotten around to exploring this extension yet, but I intend to.
These ideas need to cook a bit more. In both cases you'd have to deal with the typing issue in the extractor, and probably other things I've not thought about...
Sorry for rambling! Thanks again for starting this conversation.
-chris
Locked
