30 Apr
2006
30 Apr
'06
9:55 p.m.
For security and web, I'm a little bit paranoid,
especially at
such powerful systems like Pier ;-) I've discussed security in
Seaside/Pier with a friend, and from this I'm not sure today what I
expect from such systems like seaside/pier. He says, security
belongs only to buisness logic. I'm not so shure, also what to call
buisness logic in Pier...... I will post a related question to the
list later.
If your friend means "model" when talking about "business logic", he
is right: the security decoration is a pure model object, that works
exactly the same for all views, not just seaside one. Thanks to the
nature of visitors one can easily control how security concerns are
handled when performing operations.
You could help me understand the code answering the
following
question: in your security package, every structure element
(decorator or the decorated element) has an owner, and the the
rights of that owner decide what is possible (that the UNIX way, I
think). Is that right ?
Yes, the code modeling the unix permissions is quite simple to read,
of course you can tweak that behavior if you need to. I think it
comes quite close what unix does, but I no unix expert.
SUSecurity>>isAllowedCommand: aCommandClass in: aContext
(aContext user notNil and: [ aContext user isSuperuser ])
ifTrue: [ ^ true ].
(self owner = aContext user)
ifTrue: [ ^ self ownerCommands includes: aCommandClass ].
(self group notNil and: [ self group includes: aContext user ])
ifTrue: [ ^ self groupCommands includes: aCommandClass ].
^ self otherCommands includes: aCommandClass
But what about the commandos: is the security given by
existence
(only the commandos in structure exist, which are executable) or by
right for execution for every commando (as in UNIX file system) ?
That I have not understand until now.
I am not quite sure if I understand your question, maybe you can
deduce the answer from the above code yourself?
Basically every security decoration knows a list of all allowed
commands for the owner, the group and all the others, like the unix
"rwx", but for all available commands in the system. The security
decoration does not care what it decorates, e.g, when giving the
permission to admin to remove the root page, he still won't be able
to do that simply because the remove-command does not work on the
root, something that is enforced by the command itself.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
1 May
1 May
11:31 a.m.
New subject: Security (was: Re: Pier user in context)
Hi Lukas,
Am 30.04.2006 um 21:55 schrieb Lukas Renggli:
Yes, I know that this is a common way to think. What bothers me is
this (from a naive point of view):
- security should not something which is only be added (thats the
nature of decoration), because what was added can also be removed or
forget to add. It seems more natural to me that security is deep in
the mechanism of objects (or better message send), like the vats in E
or Islands in Croquet.
- if one say model or buisness logic, one could easily think at the
multi tier architectures. Here it is a common way to say, security
must handled be the database objects (for example), not by the
objects which are only a viewer. My problem is 1) that these viewers
are mediators of security and 2) that in complex systems this
viewers can be itself complex object with model-view architecture.
From this I would naively think, that looking at security of
buisness logic objects is not enough, or in other words, the
partitioning in model-view is not unambiguous and (in some way)
fractal. BTW, thats one point why I like Tweak, because it's
architecture adresses this problem.
But maybe I'm only paranoid :-))
Thanks for the code example, it answers indeed my question.
Regards
Hans
For security
and web, I'm a little bit paranoid, especially at
such powerful systems like Pier ;-) I've discussed security in
Seaside/Pier with a friend, and from this I'm not sure today what I
expect from such systems like seaside/pier. He says, security
belongs only to buisness logic. I'm not so shure, also what to call
buisness logic in Pier...... I will post a related question to the
list later.
If your friend means "model" when talking about "business logic", he
is right: the security decoration is a pure model object, that works
exactly the same for all views, not just seaside one. Thanks to the
nature of visitors one can easily control how security concerns are
handled when performing operations.
7:22 p.m.
New subject: Security (was: Re: Pier user in context)
Yes, I know that this is a common way to think. What
bothers me is
this (from a naive point of view):
- security should not something which is only be added (thats the
nature of decoration), because what was added can also be removed or
forget to add.
Well, as soon as the unix security package is loaded, the security
decoration adds itself automatically to all newly created structures.
There is no easy way, except by manually editing the object-graph
from the inspector, to add or remove security decorations.
It seems more natural to me that security is deep in
the mechanism of objects (or better message send), like the vats in E
or Islands in Croquet.
In my opinion this is something different. I want to keep as much as
possible pluggable in Pier, so that users with different needs can
use different security systems. There are already two security
frameworks that both work nicely, that both have advantages and
disadvantages, and that every user can decide to use or not to use.
- if one say model or buisness logic, one could easily
think at the
multi tier architectures. Here it is a common way to say, security
must handled be the database objects (for example), not by the
objects which are only a viewer. My problem is 1) that these viewers
are mediators of security and 2) that in complex systems this
viewers can be itself complex object with model-view architecture.
In Pier the security is not handled by the view, but by the model.
That is also the reason why it works in the Seaside view and in the
OmniBrowser view without additional code.
From this I would naively think, that looking at
security of
buisness logic objects is not enough, or in other words, the
partitioning in model-view is not unambiguous and (in some way)
fractal. BTW, thats one point why I like Tweak, because it's
architecture adresses this problem.
Yeah, this is true for Pier. Some logic had to be duplicated in
different views, because the (meta-)model (Magritte) is unable to
handle it in a generic way, e.g. when rendering links to HTML or a
pretty printed Text-Stream I have in both cases to manually check the
permission to be able to render the link disabled, however even it
would not be rendered disabled users would be unable to navigate
there because this would activate an invalid-context and the context
is part of the model.
Hope this clarifies some things,
Lukas
Side-note: I do not claim that the security model of Pier is secure
and impossible to break, as with everything I write as open-source it
suits my personal needs. Bug-reports, fixes and enhancements are
always welcome.
--
Lukas Renggli
http://www.lukas-renggli.ch
8:14 p.m.
New subject: Security (was: Re: Pier user in context)
Hi,
Yes, this is clear (because decorators are part of model) if looking
at "Seaside only" solutions. My statement above was made by thinking
Seaside/Pier itself as a view in a greater solution. But ok, where to
draw the borders between model and view may be somewhat academic :-)
Hope this clarifies some things,
Oh, I understand the implementation in Pier, and also the intention.
I only want to play with a different point of view ;-)
- if one say model or buisness logic, one could
easily think at the
multi tier architectures. Here it is a common way to say, security
must handled be the database objects (for example), not by the
objects which are only a viewer. My problem is 1) that these viewers
are mediators of security and 2) that in complex systems this
viewers can be itself complex object with model-view architecture.
In Pier the security is not handled by the view, but by the model.
That is also the reason why it works in the Seaside view and in the
OmniBrowser view without additional code.
Side-note: I do not claim that the security model of Pier is secure
and impossible to break, as with everything I write as open-source it
suits my personal needs. Bug-reports, fixes and enhancements are
always welcome.
Hey ! Don't be angry, I know the rules of open-source, and I never
want to be destructive. I'm only interested in different point of
views, discussions and the question "why ?" 8-) So thank you very
much for the answers. I hope we could talk a little bit further at
some SqueakNic or something like this :-)
Greetings
Hans
2 May
2 May
4:18 a.m.
New subject: Tasks
Lucas, is there a particular reason that Pier doesn't allow WATask
subclasses to be added as components?
7:19 a.m.
New subject: Tasks
Lucas, is there a particular reason that Pier
doesn't allow WATask
subclasses to be added as components?
Actually subclasses of WATask should work. In some older versions of
Pier there was a bug that a WATask rendered empty on the first
request, however I think this problem is solved in current versions
of Pier.
Can you give some more details about your task?
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
1 May
1 May
11:32 a.m.
New subject: Security (was: Re: Pier user in context)
Hi Lukas,
what I forgott: thanks for the answers, Lukas !
Regards
Hans
6563
days inactive
6565
days old
6 comments
4 participants
participants (4)
-
Hans N Beck -
Hans N Beck
-
Lukas Renggli -
Ramon Leon