Peter Speltz wrote:
> What do you mean by Maypole is confused about
> authorization/authentication. my take on Maypole
> access /authentication/authoriztion is :
> ok_tables determines access
> M::P::A:UsersessionCookie authenticates
> M::P::Authorize authorizes
I'm not an expert but the overall picture I have is that access control
is an umbrella term covering the whole subject. Authentication is the
task of identifying and verifying that a particular person or agent is
who they claim to be. Authorization is deciding whether or not an
authenticated person is entitled to take some particular action. (Just
to confuse the issue, access control lists are one implementation of
authorization). So I agree with you about M::P::A:UsersessionCookie and
M::P::Authorization, and together they are an access control system.
ok_tables is a little different, to my mind. In standard Maypole, it's
just a cache for display_tables, which in turn is an extremely simple
and limited access control system (there are tables everyone can access
and there are hidden tables that no-one can access). Once you've plugged
in a different access control system, I think its function is obsolete.
Which tables an individual user can see are determined by their roles
and the role's permissions. For most users, the authorization tables
shouldn't appear in 'ok_tables' for example.
Over time it would be better to abstract the access control functions in
standard Maypole better so that it's easier to see what they are and
what any plugin replacement needs to do. Somebody might build
replacements for all or part of the access control based on LDAP or
Kerberos or PAM, for instance.
> Ahh, this brings me to my enduring quesiton of model and view separation.
> A model knows the data and the forms of the data it needs. Its all defined in
> db shema. In short the model knows exactly what type of form it needs and the
> View knows none of this. Its the dumbest thing on the block. So my argument is
> why should I the programmer program inputs in the views? The model can do that
> so much easier since it knows what it needs.. Then the view will just worry
> about displaying them. Making things pretty. This is why i'm a big fan of
> AsForm and HTML::Element. They saved my life :).
This is probably my biggest area of confusion as well. On the one hand,
people have expressed the opinion (paraphrasing) that the templates are
the view and all of them should be customised. On the other hand,
there's the idea that templates should be maintained by graphics
designers that know no Perl. Difficult to reconcile!
I start from the viewpoint that if there's anything that would be done
differently in the way something is shown on a web page or a mobile
phone or via a telephone speech system or when everything is done in
Japanese, then that different thing belongs in the view rather than the
model. In real life, the code's a lot easier if we blur the boundary but
then the design decisions get harder to make.
Cheers, Dave
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.5 - Release Date: 26/01/05_______________________________________________ maypole mailing list maypole at lists.netthink.co.uk http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT