Disable control area in Pier
Locked
12
12
 
|
Hi,
how can I disable the bottom line with "New Session", "Toggle Halo" etc in pier ? The standard web user should not be able to make dangerous things :-) Is that a matter of seaside itself ? Regards and happy Easter ! Hans _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
hi
it it the deployment mode of all seaside application >Hi, > >how can I disable the bottom line with "New Session", "Toggle Halo" >etc in pier ? The standard web user should not be able to make >dangerous things :-) Is that a matter of seaside itself ? > > > so in the config page, go to configure (click) next to pier and set deployment mode to false >Regards and happy Easter ! > > > Thanks ;) smae for all Bye Cédrick _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
Re: Disable control area in Pier
|
|
In reply to this post by Hans N Beck
> how can I disable the bottom line with "New Session", "Toggle Halo"
> etc in pier ? The standard web user should not be able to make > dangerous things :-) Is that a matter of seaside itself ? Yes, go to /seaside/config, remove any unused applications and set "deployment mode" of your pier application to true. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
Hi,
works :-) And how to prevent that everyone can call the ../seaside/config page ? ;-) I think the removing the config is not the best :-) (Ok, this are now very basic seaside questions....) Regards Hans Am 14.04.2006 um 17:24 schrieb Lukas Renggli: >> how can I disable the bottom line with "New Session", "Toggle Halo" >> etc in pier ? The standard web user should not be able to make >> dangerous things :-) Is that a matter of seaside itself ? > > Yes, go to /seaside/config, remove any unused applications and set > "deployment mode" of your pier application to true. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
sorry for the last answer :-[ It was the opposite as Lukas said...
Hans N Beck a écrit : >Hi, > >works :-) > >And how to prevent that everyone can call the ../seaside/config >page ? ;-) I think the removing the config is not the best :-) >(Ok, this are now very basic seaside questions....) > > actually config is protected by a password so it shouldn't be accessible... ;) if you want to change it evaluate WADispatcherEditor initialize See you Cédrick _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
Hi
Am 14.04.2006 um 17:46 schrieb Cédrick Béler: > sorry for the last answer :-[ It was the opposite as Lukas said... don't worry, I've got the idea :-) > > Hans N Beck a écrit : > >> Hi, >> >> works :-) >> >> And how to prevent that everyone can call the ../seaside/config >> page ? ;-) I think the removing the config is not the best :-) >> (Ok, this are now very basic seaside questions....) >> >> > actually config is protected by a password so it shouldn't be > accessible... ;) > if you want to change it evaluate WADispatcherEditor initialize hmm, I have loaded the Pier in a clean 3.8 image (and the Pier unix security package), and there was no password needed to get the config site...... is there any default login ? Regards Hans _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
I think there is a default login when loading directly from the pier package (that manages to load all depedencies) I dont really remember but I think its login: admin pass: pier not sure at all ;)hmm, I have loaded the Pier in a clean 3.8 image (and the Pier unix security package), and there was no password needed to get the config site...... is there any default login ? anyway, the best is probably to reset the pass by evaluating WADispatcherEditor initialize an interface will ask you for a user login and password that you'll use for the page <a class="moz-txt-link-freetext" href="http://localhost:XXXX/seaside/config">http://localhost:XXXX/seaside/config See you Cédrick _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
Hi,
So now I've looked a little bit in the mailing archive, and I'm a little bit confused: It seems, - that Seaside and Pier (or any other application in Seaside) can have different security models. Both can handle its own user lists and capabilities - that there are 2 different security packages (unix inspired / ACL based) - both Seaside and Pier can add users (or user management in general) only by typing something (what ?) in workspace So if this is all true - what are the plans to make this all more integrated, so that there is only one user management, and an application may only extend the basic mechanism from seaside ? Or I'm completly wrong here ? Regards Hans Am 14.04.2006 um 18:37 schrieb Cédrick Béler:
_______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by Hans N Beck
> Hi,
> > So now I've looked a little bit in the mailing archive, and > I'm a little bit confused: > > It seems, > > - that Seaside and Pier (or any other application in Seaside) > can have different security models. Both can handle its own > user lists and capabilities > - that there are 2 different security packages (unix inspired > / ACL based) > - both Seaside and Pier can add users (or user management in > general) only by typing something (what ?) in workspace > > So if this is all true - what are the plans to make this all > more integrated, so that there is only one user management, > and an application may only extend the basic mechanism from > seaside ? Or I'm completly wrong here ? > > Regards > > Hans Pier is simply a seaside application, its user model is and should be unrelated to anything Seaside does. As far as I know, Seaside doesn't really have any security model, it's just a framework. The config application has users, which I guess you can call part of Seaside, but it's really just another app on top of Seaside like Pier. That Pier offers two security packages, is good, one is simple and written by the author of Pier, and one is more complex, especially in the UI, and offered as an add on by some other author. So, I don't they should be integrated in any way, they really aren't related. I would however, like to see more info on how to integrate custom applications meant to be hosted within Pier, with Piers default Unix Security model. How to manage and register users from the Pier UI, etc. _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by Lukas Renggli-2
Has anyone done, or seen a sample of cascading dialog boxes done with only magritte descriptions? Say I had a dropdown list of classes, and when one was selected, I want the next drop down list to contain methods in that class, or maybe countries and states, or whatever. How can the second MultipleOptionDescription get it's options: from the selector on the instance that the first MultipleOptionDescription set the value on?
_______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
winmail.dat (3K) |
|
In reply to this post by Ramon Leon
Hi Ramon,
> > Pier is simply a seaside application, its user model is and should be > unrelated to anything Seaside does. As far as I know, Seaside doesn't > really have any security model, it's just a framework. The config > application has users, which I guess you can call part of Seaside, but > it's really just another app on top of Seaside like Pier. That Pier > offers two security packages, is good, one is simple and written by > the > author of Pier, and one is more complex, especially in the UI, and > offered as an add on by some other author. So, I don't they should be > integrated in any way, they really aren't related. I would however, > like to see more info on how to integrate custom applications meant to > be hosted within Pier, with Piers default Unix Security model. How to > manage and register users from the Pier UI, etc. > OK. The reason why I said security should be integrated is because I think especially for web applications, security should not be something to install after, or to make need and decision which kind of security one want, it should be a fix and deep rooted part of such a system. like the language E. As an add on, I would afraid that this could be cracked more easily by some bad guys than if it is structural part ...... But I think also this discussion is not new. So thanks for explanation. How can I add users for the Security of Lukas (the unix ispired)? Regards Hans _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
Re: Disable control area in Pier
|
|
> But I think also this discussion is not new. So thanks for
> explanation. How can I add users for the Security of Lukas (the unix > ispired)? Sorry, that this is not possible from the web (yet), I am flooded with work and everybody is asked to contribute ;-) To answer your question: PRKernel instances -> explore the expression -> navigate to kernel of question -> navigate to the dictionary properties Now you can see two sets, one called #groups and the other one called #users, that you can modify to add and remove users. Also have a look at the implementation of PUUser and PUGroup. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by Ramon Leon
> Has anyone done, or seen a sample of cascading dialog boxes done
> with only magritte descriptions? Say I had a dropdown list of > classes, and when one was selected, I want the next drop down list > to contain methods in that class, or maybe countries and states, or > whatever. How can the second MultipleOptionDescription get it's > options: from the selector on the instance that the first > MultipleOptionDescription set the value on? Yes, however you need to specify the second description on the instance-side to be able to define it according to the state of your model. There are some examples on how to change descriptions on an instance-bases in the slides of my Magritte Tutorial (Dynamic Descriptions, 31-33) at <http://www.lukas-renggli.ch/smalltalk/ magritte>. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
I was just eating breakfast and wondering if it really makes sense to
define descriptions on the class-side. Sure this is a meta-thing, but it is not something necessarily belonging to the class as we saw in the mail of the original poster. So it would probably make more sense to put descriptions describing the instance to the instance-side, so that they can be easily created depending on the current model state. The draw-back, there is usually one, would be that retrieving the descriptions would be more expensive as they cannot be cached anymore. What do you think? Lukas On 15 Apr 2006, at 09:23, Lukas Renggli wrote: >> Has anyone done, or seen a sample of cascading dialog boxes done >> with only magritte descriptions? Say I had a dropdown list of >> classes, and when one was selected, I want the next drop down list >> to contain methods in that class, or maybe countries and states, or >> whatever. How can the second MultipleOptionDescription get it's >> options: from the selector on the instance that the first >> MultipleOptionDescription set the value on? > > Yes, however you need to specify the second description on the > instance-side to be able to define it according to the state of your > model. There are some examples on how to change descriptions on an > instance-bases in the slides of my Magritte Tutorial (Dynamic > Descriptions, 31-33) at <http://www.lukas-renggli.ch/smalltalk/ > magritte>. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by Lukas Renggli-2
Hi Lukas,
Am 15.04.2006 um 09:16 schrieb Lukas Renggli: >> But I think also this discussion is not new. So thanks for >> explanation. How can I add users for the Security of Lukas (the unix >> ispired)? > > Sorry, that this is not possible from the web (yet), I am flooded > with work and everybody is asked to contribute ;-) I think so......... :-) > > To answer your question: > > PRKernel instances > -> explore the expression > -> navigate to kernel of question > -> navigate to the dictionary properties > > Now you can see two sets, one called #groups and the other one called > #users, that you can modify to add and remove users. Also have a look > at the implementation of PUUser and PUGroup. Thanks for the answer ! Greetings Hans _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by Lukas Renggli-2
Lukas Renggli wrote:
> I was just eating breakfast and wondering if it really makes sense to > define descriptions on the class-side. Sure this is a meta-thing, but > it is not something necessarily belonging to the class as we saw in > the mail of the original poster. > > So it would probably make more sense to put descriptions describing > the instance to the instance-side, so that they can be easily created > depending on the current model state. The draw-back, there is usually > one, would be that retrieving the descriptions would be more > expensive as they cannot be cached anymore. > > What do you think? > if it is really slower? _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
> Have you tried to remove caching from existing Magritte programs to
> test if it is really slower? Sure it is much slower, I profiled it when implementing the cache. I just redid the test in the latest version and it shows that the cache improves the description retrieval by a factor of 7000, of course depending on the object hierarchy of the queried class. The reason it is so slow is basically the use of #allSelector, that could be improved (with more clever code or pragmas). Still I guess the factor of 10^3 would stay the same. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by Lukas Renggli-2
...
> The draw-back, there is usually one, would be that retrieving > the descriptions would be more expensive as they cannot be > cached anymore. Why it can be cached anymore? Can't just be posible to refactor the cache subsystem to work instance based intead of class based? I know that some systems allready have instance based caches. Some of them: GOODS client by Avi Bryant, rST, OmniBase support regards, Sebsatian PD: I'm not familiar with Magritte and recently interested in it because I think it make archivable that an application could have a maintainable web interface and desktop interface at a reasonably cost. _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by Lukas Renggli-2
>>Have you tried to remove caching from existing Magritte programs to
>>test if it is really slower? > > > Sure it is much slower, I profiled it when implementing the cache. I > just redid the test in the latest version and it shows that the cache > improves the description retrieval by a factor of 7000, of course > depending on the object hierarchy of the queried class. The reason it > is so slow is basically the use of #allSelector, that could be > improved (with more clever code or pragmas). Still I guess the factor > of 10^3 would stay the same. > > Lukas Well, being slower, doesn't at all imply that it's too slow, so a better question is in the overall rendering of a page, say a complex edit form, what percentage of total rendering time is taken by retrieving the description both cached and uncached. I mean, it could be dwarfed by the call to goods(or whatever db you use) to actually retrieve the objects, and if that's the case, running uncached may not even be noticeable. Caching may not be necessary at all, in the larger scheme of things, and frankly, I find myself flushing the cache constantly, especially during development. _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by Lukas Renggli-2
Lukas Renggli wrote:
>>Has anyone done, or seen a sample of cascading dialog boxes done >>with only magritte descriptions? Say I had a dropdown list of >>classes, and when one was selected, I want the next drop down list >>to contain methods in that class, or maybe countries and states, or >>whatever. How can the second MultipleOptionDescription get it's >>options: from the selector on the instance that the first >>MultipleOptionDescription set the value on? > > > Yes, however you need to specify the second description on the > instance-side to be able to define it according to the state of your > model. There are some examples on how to change descriptions on an > instance-bases in the slides of my Magritte Tutorial (Dynamic > Descriptions, 31-33) at <http://www.lukas-renggli.ch/smalltalk/ > magritte>. > > Cheers, > Lukas Ok, doesn't seem to work, but let me explain what I'm doing. I'm writing a component meant to be hosted in Pier, the component has several settings it needs, and I was using class side descriptions to provide the "settings" interface that Pier offers on any component. However, looking at PRSettingsComponent, I see that it's not asking the instance for it's description, it's asking the class directly, bypassing any overrides I may have attempted on the instance side. Is that the intention? Am I writing components wrong? Should I be subclassing something in Pier rather than my own WAComponent subclass? The Magritte tutorial is great btw, is there something similar for Pier? Now that Pier seems somewhat stable, I'm starting to explore it more as an application container with configurable widgets, digging it so far, just need to get a few things done so I grok the do's and dont's a little better. Great work though, keep it up! _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |