Hans N Beck | 1 May 11:32 2006
Picon

Security (was: Re: Pier user in context)

Hi Lukas,

what I forgott: thanks for the answers, Lukas !

Regards

Hans

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Hans N Beck | 1 May 11:31 2006
Picon

Security (was: Re: Pier user in context)

Hi Lukas,

Am 30.04.2006 um 21:55 schrieb Lukas Renggli:

>> 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.

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  
(Continue reading)

Lukas Renggli | 1 May 19:22 2006
Picon
Picon

Re: 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.  
(Continue reading)

Hans N Beck | 1 May 20:14 2006
Picon

Re: Security (was: Re: Pier user in context)

Hi,

>
>> - 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.

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 ;-)

>
> 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
(Continue reading)

Ramon Leon | 2 May 04:18 2006
Picon
Picon

Tasks

Lucas, is there a particular reason that Pier doesn't allow WATask 
subclasses to be added as components?

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Lukas Renggli | 2 May 07:19 2006
Picon
Picon

Re: 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

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Ramon Leon | 2 May 18:48 2006

RE: Tasks

> 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

My bad, I'd forgotten to add canBeRoot on the class side, wasn't showing
up in the component list.  Works fine.

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Ramon Leon | 2 May 23:41 2006

RE: Pier Environment Changes

> 
> I tried to change as a first step the environment (adding my 
> own layers and removing the ugly tables) using the following 
> statement:
> <div id="divHeader"><div id="divCommands">+commands+</div></div><div
> id="divLeft"><div class="boxes">+tree+</div></div><div
> id="divContents">+contents+</div>
> 
> But it seems, that this code gets escaped. Inspecting the 
> kernel and its root structure I see my HTML code as part of a 
> paragraph which seems to escape all the HTML characters...
> 
> Help is welcome! ;-)
> 
> Cheers, Chris

Are you sure that is one single string with no carrige returns anywhere?

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Lukas Renggli | 3 May 08:02 2006
Picon
Picon

Re: Pier Environment Changes

>> I tried to change as a first step the environment (adding my
>> own layers and removing the ugly tables) using the following
>> statement:
>> <div id="divHeader"><div id="divCommands">+commands+</div></div><div
>> id="divLeft"><div class="boxes">+tree+</div></div><div
>> id="divContents">+contents+</div>
>>
>> But it seems, that this code gets escaped. Inspecting the
>> kernel and its root structure I see my HTML code as part of a
>> paragraph which seems to escape all the HTML characters...
>>
>> Help is welcome! ;-)
>>
>> Cheers, Chris
>
> Are you sure that is one single string with no carrige returns  
> anywhere?

And that you have a current version of Pier, older versions put <p>  
around paragraphs and sort of turned the resulting html invalid (<p>  
and <div> are not allowed to nest into other <p>). This is fixed in  
later versions by using <div class="paragraph"> for paragraphs.

Cheers,
Lukas

--

-- 
Lukas Renggli
http://www.lukas-renggli.ch

(Continue reading)

Cédrick Béler | 4 May 12:04 2006
Picon

[Magritte] Relation description with instances of a class

Hi

Is it possible to use existing descriptions to express a relation with 
object existing or not ?

We could imagine choosing a responsible from an existing list of person 
defined by a class Person. If the person doens't exist, we can 
instanciate a new one.

I will try to create an appropriate description but I don't really know 
where to subclass as it is a bit of a mix between a 
SingleOptionDescription with instances of a class as option and a 
ToOneRelation description with class Person. What do you think ?

I ve tried with a MASingleOption description defining the reference as   
Person description and options as my repository of users but that hangs 
(due to the reference wich is a Caontainer Description I guess)... I 
also tried with MADynamicDescription without result...

that makes me ask another question... Are all MADynamicObject used with 
classes or subclasses as it is in my image ?

thanks

Cédrick

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
(Continue reading)


Gmane