[Zope-PTK] Preferences problem

[Bill Anderson]

Jochen Haeberle wrote:
> 
> At 10:17 Uhr -0500 24.02.2000, Mike Pelletier wrote:
> >On Thu, 24 Feb 2000, Jochen Haeberle wrote:
> >
> >  > I think the best would be that the http_authenticated user would have
> >  > no effect to the portal authorized users...
> >
> >     I disagree, I think this would be a Bad Thing, potentially a VERY bad
> >thing.  It would affect both the portal interface and the Zope management
> >interface.  I do agree that the caveats need to be make more visible in
> >the Wizard's finish page.
> 
> I can't see why that should be a very bad thing. I do see however
> that many people on this list have problem with the present situation
> and get confused by the user diferences. I guess those problems will
> grow very much when PTK is released and claims to be easy enough to
> anyone to set up a portal...

Consider the site that doesn't want to use cookies. If you can't use
basic authorization, you're basically sunk (pun intended).

 
> I think there already is a big difference between portal users and
> Zope users so seperating them totally would be as to go the full way.

I disagree. I am actually putting a site together that uses both.
 
> >  > Is there no way to separate portal users from Zope users? I guess
> >  > this would greatly help to solve the problems and get a better
> >  > understanding of what happens for content-manager-type portal admins.
> >
> >     Can you elabotate in the idea of separation?
> 
> This would mean that when you enter the portal logged in as a Zope
> user you will still be greated as a guest and have to log into the
> portal.

What about sites where the portal is only _part_ of the site, not _the_
site? In those cases, you're lost if you want members of the main site
to be able to be a prt of the sub-site without additional effort on
their part.
 
> >  > I find it very disturbing at the moment and have problems switching
> >  > back and forth portal and management interface the only solution was
> >  > to use virtual hosting so the http-authentication is different.
> >
> >     Not at all-- The account you set up when you create the portal has
> >full management rights and can use the Zope management interface without
> >resorting to playing tricks with the hostname.  It is more difficult if
> 
> I think the portal should be managed only through Wizards, so there
> should be no need for content managers to log into Zope aka the
> Management Interface. The problem mostly concerns developers and I
> guess they can deal with beeing logged in as separate portal and zope
> users.

Problem with this approach is that then _every_ product for Zope has to
then be converted to Portals and wizards. Something tells me this isn't
going to happen. Wizards are good for adding a specific thing, but bad
for overall layout and design.
 
> >you want to manage other portions of your site at the same time, depending
> >on your browser.  IE5 seems to do a better job of not sharing
> >authentiction information between sessions if the sessions are launched
> >separately.  (That is, don't clone the window with ^N.)
> >
> >     To be honest, I am reluctant to load the PTK up with authentication
> >hacks to solve a deficiency of some browsers.
> 
> This is the way the browsers work today. The solution you suggest
> only applies to the Win plattform - the Internet offers far more (and
> better:) OSes.

Actually, ths is an alternative to another solution (the one I use)
which works for non-windows platforms.

 
> But I can see your point to not overload the PTK!
> 
> >
> >  > I think it is not very zopic at the moment. the portal should in some
> >  > way acquire the users from above, mostly the superuser
> >
> >     The PTK _is_ acquiring users from above.  That's essentially where
> >this problem comes from-- a non-PTK user is being accquired.  I think
> >I'm not understanding you completely.  Feel free to try again.
> 
> Okay, that's what I meant... PTK acquires user from above which are
> not suited for acquisition.
> 
> How about a wizard that builds a portal user with the missing
> information? This way you could add that information missing from the
> user in the portal where need arises. Even easier but perhaps not as
> perfect as just adding the missing information would be to recreate
> the user entirely.
> 
> The PTK could check if a user is a correct portal user or not and act
> accordingly.

IMO, this can be accomplished with the use of roles.
 


-- 
In flying I have learned that carelessness and overconfidence are 
usually far more dangerous than deliberately accepted risks. 
          -- Wilbur Wright in a letter to his father, September 1900