Grok UI Manager Logout

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Grok UI Manager Logout

paul-495
I was wondering whether there's an easier way to do this.

Currently, whenever I use the grok UI manager interface, my grok
instance remains logged in as manager- so my app PAU instance detects a
valid login and doesn't allow me to log out.   I can log out my own
users at application level, but since the 'manager' identity is not
managed by my own PAU instance, I cannot seem to log out manager.

Currently, I clear the zope session cookie, close the browser tab, and
reload the URL to clear the login.   I'm sure there's an easier way, but
after much searching through the web online docs and the zope
implementation code, I'm blowed if I know what it is.

Can someone point me in the right direction?


_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev

prsephton.vcf (449 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Grok UI Manager Logout

prinzdezibel
Hi Paul,

my plain grok sandbox uses HTTP Basic Auth authentication. The credentials are sent alongside with the headers. As far as I know there's no way to logout from the session when using BasicAuth except starting a new Browser session. So I wonder if the zope session cookie you mentioned has anything to do with the authentication mechanism for the manager principal?!

Best wishes,
Michael.


On Sun, Aug 7, 2011 at 08:20, paul <[hidden email]> wrote:
I was wondering whether there's an easier way to do this.

Currently, whenever I use the grok UI manager interface, my grok instance remains logged in as manager- so my app PAU instance detects a valid login and doesn't allow me to log out.   I can log out my own users at application level, but since the 'manager' identity is not managed by my own PAU instance, I cannot seem to log out manager.

Currently, I clear the zope session cookie, close the browser tab, and reload the URL to clear the login.   I'm sure there's an easier way, but after much searching through the web online docs and the zope implementation code, I'm blowed if I know what it is.

Can someone point me in the right direction?


_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev



_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev
Reply | Threaded
Open this post in threaded view
|

Re: Grok UI Manager Logout

paul-495
Hi, Michael

Thanks for the reply.    It's quite possible that the session cookie has nothing to do with the manager login, as you say.  It's just that I picked up from the Bluebream FAQ that zope3.3 supports logout and that it's disabled by default.  The FAQ says that by including

   <adapter factory="zope.authentication.logout.LogoutSupported" />

in etc/site.zcml, one can enable logout support.  It's all pretty confusing.  A previous version of grok/zope that I used had a logout button on the management screen, and that used to work.   I do understand that basic auth (not cookie based auth) has no way of knowing when the session is closed.  Surely though, even if this is the case, one can still _tell_ the session it is closed?

Take care,
Paul

On 07/08/2011 12:31, Michael Jenny wrote:
Hi Paul,

my plain grok sandbox uses HTTP Basic Auth authentication. The credentials are sent alongside with the headers. As far as I know there's no way to logout from the session when using BasicAuth except starting a new Browser session. So I wonder if the zope session cookie you mentioned has anything to do with the authentication mechanism for the manager principal?!

Best wishes,
Michael.


On Sun, Aug 7, 2011 at 08:20, paul <[hidden email]> wrote:
I was wondering whether there's an easier way to do this.

Currently, whenever I use the grok UI manager interface, my grok instance remains logged in as manager- so my app PAU instance detects a valid login and doesn't allow me to log out.   I can log out my own users at application level, but since the 'manager' identity is not managed by my own PAU instance, I cannot seem to log out manager.

Currently, I clear the zope session cookie, close the browser tab, and reload the URL to clear the login.   I'm sure there's an easier way, but after much searching through the web online docs and the zope implementation code, I'm blowed if I know what it is.

Can someone point me in the right direction?


_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev




_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev

prsephton.vcf (616 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Grok UI Manager Logout

Miguel Beltran R.
In reply to this post by paul-495


2011/8/7 paul <[hidden email]>
I was wondering whether there's an easier way to do this.

Currently, whenever I use the grok UI manager interface, my grok instance remains logged in as manager- so my app PAU instance detects a valid login and doesn't allow me to log out.   I can log out my own users at application level, but since the 'manager' identity is not managed by my own PAU instance, I cannot seem to log out manager.

Currently, I clear the zope session cookie, close the browser tab, and reload the URL to clear the login.   I'm sure there's an easier way, but after much searching through the web online docs and the zope implementation code, I'm blowed if I know what it is.

Can someone point me in the right direction?



I do this to logout using Basic Auth.

It detect if I'm logged, if it's true then raise an unauthorized status and ask again for user and password. Just press OK and you are logout.

PageTemplate:
    <div id="cuadro-usuario"
         tal:define="usr user/getUserName">

      <div tal:condition="python: usr <> 'Anonymous User'">
        <span tal:condition="exists: request/salgo">
           <span tal:define="x context/scripts/usuario_salir"></span>
        </span>

        <span tal:content="usr"></span>
           <a tal:attributes="href python:request.BASE2 + '?salgo=true'"
              target="_parent"> - Logout</a>
      </div>


      <div tal:condition="python: usr == 'Anonymous User'">
        <span tal:condition="exists: request/entro">
           <span tal:define="x context/scripts/usuario_entrar"></span>
        </span>

          <a tal:attributes="href python:request.BASE2 + '?entro=true'"
              target="_parent">Login</a>
       </div>
        
    </div>


<usuario_entrar>:
request = container.REQUEST
response =  request.RESPONSE

response.setStatus('Unauthorized')
response.setHeader('WWW-Authenticate', 'basic realm="OPTIMUSMX', 1)


<usuario_salir>:
request = container.REQUEST
response =  request.RESPONSE

response.setHeader('WWW-Authenticate', 'basic realm="OPTIMUSMX', 1)
response.setStatus('Unauthorized')



--
________________________________________
Lo bueno de vivir un dia mas
es saber que nos queda un dia menos de vida

_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev
Reply | Threaded
Open this post in threaded view
|

Re: Grok UI Manager Logout

paul-495
Thank you, Miguel!   If I could speak Spanish, I would thank you a million times in Spanish!

This works like a charm!

On 08/08/2011 16:13, Miguel Beltran R. wrote:


2011/8/7 paul <[hidden email]>
I was wondering whether there's an easier way to do this.

Currently, whenever I use the grok UI manager interface, my grok instance remains logged in as manager- so my app PAU instance detects a valid login and doesn't allow me to log out.   I can log out my own users at application level, but since the 'manager' identity is not managed by my own PAU instance, I cannot seem to log out manager.

Currently, I clear the zope session cookie, close the browser tab, and reload the URL to clear the login.   I'm sure there's an easier way, but after much searching through the web online docs and the zope implementation code, I'm blowed if I know what it is.

Can someone point me in the right direction?



I do this to logout using Basic Auth.

It detect if I'm logged, if it's true then raise an unauthorized status and ask again for user and password. Just press OK and you are logout.

PageTemplate:
    <div id="cuadro-usuario"
         tal:define="usr user/getUserName">

      <div tal:condition="python: usr <> 'Anonymous User'">
        <span tal:condition="exists: request/salgo">
           <span tal:define="x context/scripts/usuario_salir"></span>
        </span>

        <span tal:content="usr"></span>
           <a tal:attributes="href python:request.BASE2 + '?salgo=true'"
              target="_parent"> - Logout</a>
      </div>


      <div tal:condition="python: usr == 'Anonymous User'">
        <span tal:condition="exists: request/entro">
           <span tal:define="x context/scripts/usuario_entrar"></span>
        </span>

          <a tal:attributes="href python:request.BASE2 + '?entro=true'"
              target="_parent">Login</a>
       </div>
        
    </div>


<usuario_entrar>:
request = container.REQUEST
response =  request.RESPONSE

response.setStatus('Unauthorized')
response.setHeader('WWW-Authenticate', 'basic realm="OPTIMUSMX', 1)


<usuario_salir>:
request = container.REQUEST
response =  request.RESPONSE

response.setHeader('WWW-Authenticate', 'basic realm="OPTIMUSMX', 1)
response.setStatus('Unauthorized')



--
________________________________________
Lo bueno de vivir un dia mas
es saber que nos queda un dia menos de vida


_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev

prsephton.vcf (449 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Grok UI Manager Logout

Miguel Beltran R.


2011/8/8 paul <[hidden email]>
Thank you, Miguel!   If I could speak Spanish, I would thank you a million times in Spanish!

This works like a charm!



You are welcome, I learned the code in the zope2 list :D

_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev
Reply | Threaded
Open this post in threaded view
|

Re: Grok UI Manager Logout

Sebastian Ware
Maybe someone could implement this in the Grok Admin UI?

Mvh Sebastian

9 aug 2011 kl. 05.06 skrev Miguel Beltran R.:

>
>
> 2011/8/8 paul <[hidden email]>
> Thank you, Miguel!   If I could speak Spanish, I would thank you a million times in Spanish!
>
> This works like a charm!
>
>
>
> You are welcome, I learned the code in the zope2 list :D
> _______________________________________________
> Grok-dev mailing list
> [hidden email]
> https://mail.zope.org/mailman/listinfo/grok-dev


_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev
Reply | Threaded
Open this post in threaded view
|

Re: Grok UI Manager Logout

Uli Fouquet
Hi there,

Sebastian Ware wrote:

> Maybe someone could implement this in the Grok Admin UI?

I personally won't and I hope nobody else will do.

The problem with the mentioned approach, if I understood it correctly,
is that it only 'logs out' someone for the mentioned view. The 'logout'
is artificially triggered bypassing the authentication system and won't
work for other pages unless they each do the same thing. 'Bypassing'
here means: it triggers Unauthenticated although the underlying
authentication system won't do that.

So for me, unfortunately, Miguels approach does not work like a charm
(but I might have misunderstood something while translating it into
'grokkish').

Instead, I think, the browser will happily continue to send the
credentials with requests to other pages in the same realm. The whole
authentication system does not make much sense under that circumstances
any more. So, if we would have that sort of 'logout' in the admin UI
(and each page of the admin UI) a manager user, once logged in, would
still be authenticated in some third-party app, even if the user clicked
logout there. Please correct me if I'm wrong but this would bring even
more confusion into the authentication story.

It is, BTW, true that we had some logout button in admin UI some years
ago but at that time we also had the admin UI implementing an own
(session/cookie-based, not: basic-auth) authentication. You could enter
the credentials via a login page. This was generally considered a bad
approach (it could confuse apps implementing an own authentication, was
not compatible with more extreme use-cases like ZODB-less usage, etc.)
so we removed this authentication and went back to basic-auth.

I am also pretty sure that dolmen has something to offer to ease these
pretty common tasks.

Best regards,

--
Uli


_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Grok UI Manager Logout

paul-495
On 09/08/2011 15:37, Uli Fouquet wrote:
> The problem with the mentioned approach, if I understood it correctly,
> is that it only 'logs out' someone for the mentioned view.
Miguel's approach is to challenge the browser with a 401 for a different
realm than the one used by the manager interface.

I'm no expert on basic auth here, but I believe the browser keeps a
site/realm/credentials table available which, if there is a match,
allows the browser to re-use the credentials to re-authenticate whenever
it needs to.  The act of prompting the browser to fail authentication
appears to clear the table entry.  From what I understand, the browser
keeps one active realm per site, and one browser instance cannot be
authenticated with more than one realm for the same site.

Regarding implementing Miguel's browser challenge in the manager
interface? Perhaps it's not necessarily a good idea.  It could cause
conflict with application PAU implementations.  It's easy enough to
implement in the app if necessary- once one knows about this approach.

Feel free to correct my scanty knowledge...

Kind regards,
Paul


_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev

prsephton.vcf (449 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Grok UI Manager Logout

Uli Fouquet
Hi Paul,

paul wrote:

> On 09/08/2011 15:37, Uli Fouquet wrote:
> > The problem with the mentioned approach, if I understood it correctly,
> > is that it only 'logs out' someone for the mentioned view.
> Miguel's approach is to challenge the browser with a 401 for a different
> realm than the one used by the manager interface.

Yes, that was mainly in reply to Sebastians wish to make the admin UI
implement it. Therefore I took the liberty to try the approach with the
'Zope' realm. The result is as expected: if I protect a
localhost/myapp/view1 page and do 'logout' on it, I can still access
localhost/, localhost/myapp/otherview, etc. That is not exactly, what I
would expect from a logout ;)

>
> I'm no expert on basic auth here,

Me neither, really.

> but I believe the browser keeps a
> site/realm/credentials table available which, if there is a match,
> allows the browser to re-use the credentials to re-authenticate whenever
> it needs to.  The act of prompting the browser to fail authentication
> appears to clear the table entry.  From what I understand, the browser
> keeps one active realm per site, and one browser instance cannot be
> authenticated with more than one realm for the same site.

Well, from http://www.ietf.org/rfc/rfc2617.txt , section 2, I learn that

  "A client SHOULD assume that all paths at or deeper than the depth of
   the last symbolic element in the path field of the Request-URI also
   are within the protection space specified by the Basic realm value of
   the current challenge."

That would mean that if I protect http://localhost/myapp/index, I have
to do that again for http://localhost/myapp/fancystuff and so on, until
a user really requests http://localhost/myapp/ (which then _should_
protect the complete 'deeper' tree of possible URIs).

You might also notice that the above HTTP specification says nothing
about 'forgetting' basic auth credentials. It only tells that this is
mainly a client thing which is bad enough for a server software. So,
it's up to the browser.

Okay, but let's think about grokui.admin doing this approach anyway.
Overall, it looks like implementing the whole thing in
grokui.admin/grokui.base where we have access to the 'index' view of the
root could do the trick, right? Logging out from http://localhost:8080/
then should give the basic-auth login widget popping up whenever this
specific user tries to access some protected page from localhost, right?

Unfortunately this is only partly the case. It seems to work with
Firefox but it doesn't work for example with the (outdated, I admit)
Opera version I have installed locally. With it I can still access
subpages as zope.manager, even if I logged out from
http://localhost:8080/ using Miguels hack. And by doing so, Opera does
not violate the HTTP specification. In other words: sending 401 and
hoping that the client forgets all auth-infos seems not to be safe.

Furthermore you bypass the Zope authentication system with its security
policy and might run into further, difficult to spot security problems.

For that reasons I wouldn't really like to see that 'feature' in grokui.
For real session-based authentication (with logout and all that) I would
instead recommend an own PAU  with sessions, cookies and login-screens.
That not only works consistently on different browser types and is more
secure, it also simply looks better ;)

If we could simplify that task with Grok, I'm really willing to help.
Please just tell, what kind of improvements you could imagine. How
should a really simple authentication setup look like (code-wise) from
your point of view? What are the main problems?

For people really having problems with basic auth logout that use
Firefox, maybe the Web Developer extension is a solution:

  https://addons.mozilla.org/de/firefox/addon/web-developer/?id=60

or this add-on:

  https://addons.mozilla.org/de/firefox/addon/http-logout/

They provide deletion of HTTP basic auth caches on request. And they
work for all sites that use basic auth, not only Grok/Zope/Bluebream.

> Regarding implementing Miguel's browser challenge in the manager
> interface? Perhaps it's not necessarily a good idea.  It could cause
> conflict with application PAU implementations.  It's easy enough to
> implement in the app if necessary- once one knows about this approach.

Right, if you know what you do and are aware that it might not work with
all browsers, I'd agree :)

Best regards,

--
Uli


_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Grok UI Manager Logout

paul-495
On 10/08/2011 11:53, Uli Fouquet wrote:
> Yes, that was mainly in reply to Sebastians wish to make the admin UI
> implement it. Therefore I took the liberty to try the approach with
> the 'Zope' realm. The result is as expected: if I protect a
> localhost/myapp/view1 page and do 'logout' on it, I can still access
> localhost/, localhost/myapp/otherview, etc. That is not exactly, what
> I would expect from a logout ;)
>> I'm no expert on basic auth here,
> Me neither, really.
I beg to differ...

>> The act of prompting the browser to fail authentication
>> appears to clear the table entry.  From what I understand, the browser
>> keeps one active realm per site, and one browser instance cannot be
>> authenticated with more than one realm for the same site.
> Well, from http://www.ietf.org/rfc/rfc2617.txt , section 2, I learn that
>
>    "A client SHOULD assume that all paths at or deeper than the depth of
>     the last symbolic element in the path field of the Request-URI also
>     are within the protection space specified by the Basic realm value of
>     the current challenge."
It's a bit confusing- to me at least.  Assuming the root of the
traversal tree is protected; Does that mean that elements beneath the
root cannot carry different protection than that of the root, or does it
mean that the root elements protection extends and supplements that of
the sub-elements?

One thing did strike me; what would be the effect, were one to cycle the
value of the 'Basic realm' for the same url?
eg:
    Server                                         Browser
~~~~~~                                ~~~~~~~~

<--------     Request http://
    401: realm="Zope"   ------->
<-------      Base64Cred
    htmldata                    ------->
<time passes>
<------       Logout URL
   (Set session flag, Redirect root)
    301:   Redirect           ------->
<--------     Request http://
   (Check session flag, reset flag)
    401:realm="Invalid" ------->
<------       Re-prompt user (cannot find realm=Invalid for "current
challenge")

> You might also notice that the above HTTP specification says nothing
> about 'forgetting' basic auth credentials. It only tells that this is
> mainly a client thing which is bad enough for a server software. So,
> it's up to the browser.
That's the crux of it, certainly.  And different browsers do whatever
they think is best given lack of specification.  So there's no
consistent behaviour we can rely on.

> Okay, but let's think about grokui.admin doing this approach anyway.
> Overall, it looks like implementing the whole thing in
> grokui.admin/grokui.base where we have access to the 'index' view of the
> root could do the trick, right? Logging out from http://localhost:8080/
> then should give the basic-auth login widget popping up whenever this
> specific user tries to access some protected page from localhost, right?
>
> Unfortunately this is only partly the case. It seems to work with
> Firefox but it doesn't work for example with the (outdated, I admit)
> Opera version I have installed locally. With it I can still access
> subpages as zope.manager, even if I logged out from
> http://localhost:8080/ using Miguels hack. And by doing so, Opera does
> not violate the HTTP specification. In other words: sending 401 and
> hoping that the client forgets all auth-infos seems not to be safe.
Precisely.  At least keep the manager interface behaviour consistent
across browsers.  It's not really that much of a problem, as such, more
of an irritation.  The fact that the manager i/f uses basic auth doesn't
affect the site users at all, just the person managing it.  So, for
arguments sake, were you to change the manager i/f in some way, the
change would be affecting only the site developers anyway.  There's
probably better use for your time.

I would argue that it's probably worth documenting the issue though,
which is in a way what we are doing right now.

> If we could simplify that task with Grok, I'm really willing to help.
> Please just tell, what kind of improvements you could imagine. How
> should a really simple authentication setup look like (code-wise) from
> your point of view? What are the main problems?
And that's the real question.  After understanding the issue, what can
be done about it?  As far as I can see, so long as the Grok-UI uses
basic auth (and there's a good reason for that as I understand), and
browsers don't behave consistently regarding 'forgetting' creds, there's
not much that can be done at a general level.  Perhaps someone else has
some bright spark ideas, but I'm all out :-)

Kind regards, and thanks for your in-depth response to this question,

Paul


_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev

prsephton.vcf (449 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Grok UI Manager Logout

Miguel Beltran R.
In reply to this post by Uli Fouquet
 

Unfortunately this is only partly the case. It seems to work with
Firefox but it doesn't work for example with the (outdated, I admit)
Opera version I have installed locally. With it I can still access
subpages as zope.manager, even if I logged out from
http://localhost:8080/ using Miguels hack. And by doing so, Opera does
not violate the HTTP specification. In other words: sending 401 and
hoping that the client forgets all auth-infos seems not to be safe.


It's good to know, I only use firefox.





_______________________________________________
Grok-dev mailing list
[hidden email]
https://mail.zope.org/mailman/listinfo/grok-dev