Re: Re: why is authorization in a separate layer from the model?

Caleb Cushing <[email protected]>
Newsgroups gmane.comp.programming.domain-driven-design
Message-ID <CAAHKNRF2M224BQRkJvhA0cAU1gNzQDPvP+tcKK1HUXsSC28zXw@mail.gmail.com>
On Mon, Mar 11, 2013 at 2:02 AM, vvernon_shiftmethod
<[email protected]> wrote:
> Take a look at IDDD pages 75-79, and specifically at the refactored code on pages 78-79. It's not that it is absolutely wrong to in essence authorize the user in the model. Rather, it's that the authorization is done for free when obtaining the necessary Author instance from the CollaboratorService.
>
> Further, it's a matter that the Author is an essential part of the Ubiquitous Language, while your Session is not. If anything, rather than pass in Session (or worse yet, SecuritySession), pass in CollaboratorService instead, and use CollaboratorService to get the Author from the Forum's own Tenant and parameter String anAuthorId.

well I understood how /author/ was an important concept.

> In my sample code I show the Forum Application Service obtaining the Author via CollaboratorService. This is not wrong, because normally the API would serve as the natural client of the model. When using the Hexagonal (Ports and Adapters) architecture, requests from disparate user agent types would all be adapted to use a single API call. This is based on use case, not on user agent type. But you could pass in CollaboratorService to the Forum if you prefer.

I think perhaps I simply do not yet understand what you're doing with
CollaboratorService, and definitely need to try to understand the
Hexagonal Architecture. I'm going to go back in and look at these
pieces for sure tonight. My only thought though (and it doesn't fit
real well in this context) is that what if author is more metadata?
what if the person making the change is not the author but... some
agent of the author, say the author's editor.

In the case I was actually working on I was looking more at a ticket
system with Ticket Owner where the Owner could be different from the
Author and whom the ticket was AssignedTo. I was going to derive
Author from the current User, and and Owner if the current user was a
Customer. I was still need to check does the current (Security
Session/Context/ w/e ) User/Role have access to create in this Queue
and for this Owner.

-- 
Caleb Cushing

http://xenoterracide.com


------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.