Re: [Freeipa-devel] Summary of Session discussion

2011-05-26 Thread Simo Sorce
On Thu, 2011-05-26 at 12:53 -0400, Adam Young wrote:
 There are four cases where we've discussed using sessions for 
 optimizations.  During today's phone discussion we analysed them.
 
 1.  Avoiding the negotiate round trip.
 
 Requesting a page protected by Kerberos requires two round trips to the 
 server:  1 for the initializ request, which gets denied with the 
 negotiate challenge, and one for the negotiate response.  mod_auth_kerb 
 can fall back to userid/password.  THe suggestion was t hat we allow 
 mod_auth_kerb to set a session cookie after a successful negotiate 
 request.  Future requests can use that cookie to bypass the negotiate 
 handshake.  The problem with this approach is NFS home directories,

Can you expand the reasoning about NFS home directories ?

  and 
 root users being able to get  access to the session cookies, allowing a 
 replay attack.

Root can simply steal your TGT, that is not a concern we have any reason
to raise here.

   Note that this is a problem with the userid/password 
 fall-back as well.  We are not going to pursue this right now.

We are not going to pursue using sessions ? Or concerning ourselves with
these issues ? :)

 2.  Caching the service ticket.  Once the http request has gone through, 
 the ipa web server needs to request a service ticket for LDAP.  If the 
 session contained the service ticket, the could be bypassed for 
 additional requests.  Since the request has to be validated by Kerberos 
 for the initial negotiate call, there is no additional loss of security 
 in caching the ticket.

Indeed.

  A potential alternative to server side caching is for the client to 
 request the service ticket and send it in the negotiate handshake.  
 There is some question as to whether the web server would be able to 
 acces this ticket, and also whether the client can somehow request a 
 ticket that the server can use, and still comply with the Kerberos 
 standards.

This should be possible, but there is no client that can do that right
now, and changing clients is simply out of our reach in most cases.

 3.  File Upload.  Session time out provides a means to automate the 
 clean up of files that might otherwise be orphaned.

What kind of files ?

 4.  Windowing search results.  the 'find' APIs as implemented by LDAP 
 limit the responses to 200 records by default.  One request we've had is 
 to provide sorting and windowing.  Windowing here is defined as, for a 
 sorted response, return a delimited number of records starting at an 
 offset greater than 0. The LDAP implementation requires the equivalent 
 of a cursor from the requester, in this case the Apache server.  To 
 maintain association between the user and the cursor, the cursor 
 identifier would be stored in the session.   Implementing this correctly 
 will require further design.  It will likely be done in the future.

The cursor need also to be associated to a specific query, cannot be
just a session-global variable.

 In summary, the caching of the service ticket alone provides a 
 compelling reason to implement sessions.  File upload will take 
 advantage of them.  Other uses may be found over time.

Very good, thanks for taking up on this analysis task.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] Summary of Session discussion

2011-05-26 Thread Dmitri Pal
On 05/26/2011 02:01 PM, Simo Sorce wrote:
 On Thu, 2011-05-26 at 12:53 -0400, Adam Young wrote:
 There are four cases where we've discussed using sessions for 
 optimizations.  During today's phone discussion we analysed them.

 1.  Avoiding the negotiate round trip.

 Requesting a page protected by Kerberos requires two round trips to the 
 server:  1 for the initializ request, which gets denied with the 
 negotiate challenge, and one for the negotiate response.  mod_auth_kerb 
 can fall back to userid/password.  THe suggestion was t hat we allow 
 mod_auth_kerb to set a session cookie after a successful negotiate 
 request.  Future requests can use that cookie to bypass the negotiate 
 handshake.  The problem with this approach is NFS home directories,
 Can you expand the reasoning about NFS home directories ?

Cookie can be stored on the home directory of the user and user home
directory can be NFS mounted so if we save anything important in the
cookie the NFS root would be able to impersonate the user. It assumes
that TGTs are not stored on the NFS in this case so replacing the TGT
auth with fast session cookie auth would be a security issue.
I hope I understand the issue correctly.

  and 
 root users being able to get  access to the session cookies, allowing a 
 replay attack.
 Root can simply steal your TGT, that is not a concern we have any reason
 to raise here.

NFS root?

   Note that this is a problem with the userid/password 
 fall-back as well.  We are not going to pursue this right now.
 We are not going to pursue using sessions ? Or concerning ourselves with
 these issues ? :)

We are not going to try to avoid kerberos renegotiation on every request.
Hm should we consider something like Oauth in this case?

 2.  Caching the service ticket.  Once the http request has gone through, 
 the ipa web server needs to request a service ticket for LDAP.  If the 
 session contained the service ticket, the could be bypassed for 
 additional requests.  Since the request has to be validated by Kerberos 
 for the initial negotiate call, there is no additional loss of security 
 in caching the ticket.
 Indeed.


In any case if we cache the ldap ticket we need to get it from the cache
before finishing the request.
The question came up: is the python-kerberos/krbV packages provide the
interface to the CC to get the ticket.

  A potential alternative to server side caching is for the client to 
 request the service ticket and send it in the negotiate handshake.  
 There is some question as to whether the web server would be able to 
 acces this ticket, and also whether the client can somehow request a 
 ticket that the server can use, and still comply with the Kerberos 
 standards.
 This should be possible, but there is no client that can do that right
 now, and changing clients is simply out of our reach in most cases.


We can do it in the XML-RPC/JSON outside of kerberos but is it worth it?
We need to extract the ticket first.

 3.  File Upload.  Session time out provides a means to automate the 
 clean up of files that might otherwise be orphaned.
 What kind of files ?

Entitlements

 4.  Windowing search results.  the 'find' APIs as implemented by LDAP 
 limit the responses to 200 records by default.  One request we've had is 
 to provide sorting and windowing.  Windowing here is defined as, for a 
 sorted response, return a delimited number of records starting at an 
 offset greater than 0. The LDAP implementation requires the equivalent 
 of a cursor from the requester, in this case the Apache server.  To 
 maintain association between the user and the cursor, the cursor 
 identifier would be stored in the session.   Implementing this correctly 
 will require further design.  It will likely be done in the future.
 The cursor need also to be associated to a specific query, cannot be
 just a session-global variable.

You can limit it to have one cursor open per session at a time so you
can use it as session global.
You do not need to have to queries paginated at the same time from UI so
there is no need to keep more than one cursor.

 In summary, the caching of the service ticket alone provides a 
 compelling reason to implement sessions.  File upload will take 
 advantage of them.  Other uses may be found over time.
 Very good, thanks for taking up on this analysis task.

 Simo.



-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] Summary of Session discussion

2011-05-26 Thread Simo Sorce
On Thu, 2011-05-26 at 14:19 -0400, Dmitri Pal wrote:
 On 05/26/2011 02:01 PM, Simo Sorce wrote:
  On Thu, 2011-05-26 at 12:53 -0400, Adam Young wrote:
  There are four cases where we've discussed using sessions for 
  optimizations.  During today's phone discussion we analysed them.
 
  1.  Avoiding the negotiate round trip.
 
  Requesting a page protected by Kerberos requires two round trips to the 
  server:  1 for the initializ request, which gets denied with the 
  negotiate challenge, and one for the negotiate response.  mod_auth_kerb 
  can fall back to userid/password.  THe suggestion was t hat we allow 
  mod_auth_kerb to set a session cookie after a successful negotiate 
  request.  Future requests can use that cookie to bypass the negotiate 
  handshake.  The problem with this approach is NFS home directories,
  Can you expand the reasoning about NFS home directories ?
 
 Cookie can be stored on the home directory of the user and user home
 directory can be NFS mounted so if we save anything important in the
 cookie the NFS root would be able to impersonate the user. It assumes
 that TGTs are not stored on the NFS in this case so replacing the TGT
 auth with fast session cookie auth would be a security issue.
 I hope I understand the issue correctly.

We can store the the cookie in the ccache, so that we have it in the
same place the TGT is. We shouldn't save it in the home, as it is
insecure indeed.

   and 
  root users being able to get  access to the session cookies, allowing a 
  replay attack.
  Root can simply steal your TGT, that is not a concern we have any reason
  to raise here.
 
 NFS root?

if by NFS root you mean the root user on the NFS server serving out
your home directories the answer is no. As the ccache is stored in files
local to the system.

Note that this is a problem with the userid/password 
  fall-back as well.  We are not going to pursue this right now.
  We are not going to pursue using sessions ? Or concerning ourselves with
  these issues ? :)
 
 We are not going to try to avoid kerberos renegotiation on every request.

Why not ?
Unless you have other concerns the one expressed above are all
non-issues.

 Hm should we consider something like Oauth in this case?

It would have exactly the same issues except it will be more complex to
implement, so if you can do one you can do the other.

  2.  Caching the service ticket.  Once the http request has gone through, 
  the ipa web server needs to request a service ticket for LDAP.  If the 
  session contained the service ticket, the could be bypassed for 
  additional requests.  Since the request has to be validated by Kerberos 
  for the initial negotiate call, there is no additional loss of security 
  in caching the ticket.
  Indeed.
 
 
 In any case if we cache the ldap ticket we need to get it from the cache
 before finishing the request.

EPARSE.

 The question came up: is the python-kerberos/krbV packages provide the
 interface to the CC to get the ticket.

If python-krbV doesn't yet it should be relatively easy to add,l I
expect no more than a couple days work to add enough functionality if it
is not there.

   A potential alternative to server side caching is for the client to 
  request the service ticket and send it in the negotiate handshake.  
  There is some question as to whether the web server would be able to 
  acces this ticket, and also whether the client can somehow request a 
  ticket that the server can use, and still comply with the Kerberos 
  standards.
  This should be possible, but there is no client that can do that right
  now, and changing clients is simply out of our reach in most cases.
 
 
 We can do it in the XML-RPC/JSON outside of kerberos but is it worth it?

No, we do not want to get in the business of forwarding credential
caches outside of the standard protocols, *that* is asking for trouble.

 We need to extract the ticket first.

You do not have direct access to the credential cache from within the
browser so you wouldn't be able to do that for the WebUI anyway.

Building a whole mechanism like that just to optimized the CLI when we
can do a much better job server side looks like a waste, plus it would
force third party implementations that want to use the XML-RPC channel
to do things they may possible not be able to do either, forcing them to
the less efficient way. Not good.

  3.  File Upload.  Session time out provides a means to automate the 
  clean up of files that might otherwise be orphaned.
  What kind of files ?
 
 Entitlements

I guess I miss too many details to understand this point, but given it
doesn't seem to be relevant to the security aspect I think I'll just
ignore for now.

  4.  Windowing search results.  the 'find' APIs as implemented by LDAP 
  limit the responses to 200 records by default.  One request we've had is 
  to provide sorting and windowing.  Windowing here is defined as, for a 
  sorted response, return a delimited number of records 

Re: [Freeipa-devel] Summary of Session discussion

2011-05-26 Thread Adam Young

On 05/26/2011 02:01 PM, Simo Sorce wrote:

On Thu, 2011-05-26 at 12:53 -0400, Adam Young wrote:

There are four cases where we've discussed using sessions for
optimizations.  During today's phone discussion we analysed them.

1.  Avoiding the negotiate round trip.

Requesting a page protected by Kerberos requires two round trips to the
server:  1 for the initializ request, which gets denied with the
negotiate challenge, and one for the negotiate response.  mod_auth_kerb
can fall back to userid/password.  THe suggestion was t hat we allow
mod_auth_kerb to set a session cookie after a successful negotiate
request.  Future requests can use that cookie to bypass the negotiate
handshake.  The problem with this approach is NFS home directories,

Can you expand the reasoning about NFS home directories ?


As Stephen Gallagher points out, Secure cookies are held in memory, not 
on disk.  However, the ipa client is a complete process, and it would 
need to be able to store the cookie somewhere for CLI to use.



  and
root users being able to get  access to the session cookies, allowing a
replay attack.

Root can simply steal your TGT, that is not a concern we have any reason
to raise here.


I might have root on a machine that can mount via NFS, and thus allow me 
to su to your account, and get read access to your home directory.  I 
don't need root on your machine.  BBut again, only an issue if the 
session cookie got written to disk, which shouldn't happen with session 
cookies.

   Note that this is a problem with the userid/password
fall-back as well.  We are not going to pursue this right now.

We are not going to pursue using sessions ? Or concerning ourselves with
these issues ? :)


I think we are not going to pursue the mod_auth_kerb streamlining I 
outline, at least not in the short term.  An additional issue is getting 
the update to mod_auth_kerb accepted.  I'd say we can purse this in 
parallel, as I think it will be a valuable performance optimisation, but 
it does not have to be part of the IPA work per-se.



2.  Caching the service ticket.  Once the http request has gone through,
the ipa web server needs to request a service ticket for LDAP.  If the
session contained the service ticket, the could be bypassed for
additional requests.  Since the request has to be validated by Kerberos
for the initial negotiate call, there is no additional loss of security
in caching the ticket.

Indeed.


  A potential alternative to server side caching is for the client to
request the service ticket and send it in the negotiate handshake.
There is some question as to whether the web server would be able to
acces this ticket, and also whether the client can somehow request a
ticket that the server can use, and still comply with the Kerberos
standards.

This should be possible, but there is no client that can do that right
now, and changing clients is simply out of our reach in most cases.

Yes, and thus we are not going to pursue that approach.


3.  File Upload.  Session time out provides a means to automate the
clean up of files that might otherwise be orphaned.

What kind of files ?

Certificates and automount maps are the two we've discussed recently.


4.  Windowing search results.  the 'find' APIs as implemented by LDAP
limit the responses to 200 records by default.  One request we've had is
to provide sorting and windowing.  Windowing here is defined as, for a
sorted response, return a delimited number of records starting at an
offset greater than 0. The LDAP implementation requires the equivalent
of a cursor from the requester, in this case the Apache server.  To
maintain association between the user and the cursor, the cursor
identifier would be stored in the session.   Implementing this correctly
will require further design.  It will likely be done in the future.

The cursor need also to be associated to a specific query, cannot be
just a session-global variable.
Agreed.  It means that subsequent API calls can reuse a specific 
query.But we want it to be optional, or there would be significant 
overhead, and thus we'll postpone this approach for now.




In summary, the caching of the service ticket alone provides a
compelling reason to implement sessions.  File upload will take
advantage of them.  Other uses may be found over time.

Very good, thanks for taking up on this analysis task.

Simo.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] Summary of Session discussion

2011-05-26 Thread Adam Young

On 05/26/2011 02:19 PM, Dmitri Pal wrote:

On 05/26/2011 02:01 PM, Simo Sorce wrote:

On Thu, 2011-05-26 at 12:53 -0400, Adam Young wrote:

There are four cases where we've discussed using sessions for
optimizations.  During today's phone discussion we analysed them.

1.  Avoiding the negotiate round trip.

Requesting a page protected by Kerberos requires two round trips to the
server:  1 for the initializ request, which gets denied with the
negotiate challenge, and one for the negotiate response.  mod_auth_kerb
can fall back to userid/password.  THe suggestion was t hat we allow
mod_auth_kerb to set a session cookie after a successful negotiate
request.  Future requests can use that cookie to bypass the negotiate
handshake.  The problem with this approach is NFS home directories,

Can you expand the reasoning about NFS home directories ?

Cookie can be stored on the home directory of the user and user home
directory can be NFS mounted so if we save anything important in the
cookie the NFS root would be able to impersonate the user. It assumes
that TGTs are not stored on the NFS in this case so replacing the TGT
auth with fast session cookie auth would be a security issue.
I hope I understand the issue correctly.


NOt secure cookies, so it is only an issue for the CLI.  If the CLI can 
store the cookine in the key store, then we don't havea problem.

  and
root users being able to get  access to the session cookies, allowing a
replay attack.

Root can simply steal your TGT, that is not a concern we have any reason
to raise here.

NFS root?
Root user on a different machine that is allowed to mount NFS has pretty 
much complete access to the NFS directories.  The root user can su to an 
user on the system.



   Note that this is a problem with the userid/password
fall-back as well.  We are not going to pursue this right now.

We are not going to pursue using sessions ? Or concerning ourselves with
these issues ? :)

We are not going to try to avoid kerberos renegotiation on every request.
Hm should we consider something like Oauth in this case?


OAuth suffers from the same issues.

2.  Caching the service ticket.  Once the http request has gone through,
the ipa web server needs to request a service ticket for LDAP.  If the
session contained the service ticket, the could be bypassed for
additional requests.  Since the request has to be validated by Kerberos
for the initial negotiate call, there is no additional loss of security
in caching the ticket.

Indeed.


In any case if we cache the ldap ticket we need to get it from the cache
before finishing the request.
The question came up: is the python-kerberos/krbV packages provide the
interface to the CC to get the ticket.


  A potential alternative to server side caching is for the client to
request the service ticket and send it in the negotiate handshake.
There is some question as to whether the web server would be able to
acces this ticket, and also whether the client can somehow request a
ticket that the server can use, and still comply with the Kerberos
standards.

This should be possible, but there is no client that can do that right
now, and changing clients is simply out of our reach in most cases.


We can do it in the XML-RPC/JSON outside of kerberos but is it worth it?
We need to extract the ticket first.


3.  File Upload.  Session time out provides a means to automate the
clean up of files that might otherwise be orphaned.

What kind of files ?

Entitlements


4.  Windowing search results.  the 'find' APIs as implemented by LDAP
limit the responses to 200 records by default.  One request we've had is
to provide sorting and windowing.  Windowing here is defined as, for a
sorted response, return a delimited number of records starting at an
offset greater than 0. The LDAP implementation requires the equivalent
of a cursor from the requester, in this case the Apache server.  To
maintain association between the user and the cursor, the cursor
identifier would be stored in the session.   Implementing this correctly
will require further design.  It will likely be done in the future.

The cursor need also to be associated to a specific query, cannot be
just a session-global variable.

You can limit it to have one cursor open per session at a time so you
can use it as session global.
You do not need to have to queries paginated at the same time from UI so
there is no need to keep more than one cursor.


In summary, the caching of the service ticket alone provides a
compelling reason to implement sessions.  File upload will take
advantage of them.  Other uses may be found over time.

Very good, thanks for taking up on this analysis task.

Simo.





___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] Summary of Session discussion

2011-05-26 Thread Stephen Gallagher
On Thu, 2011-05-26 at 14:43 -0400, Simo Sorce wrote:
 On Thu, 2011-05-26 at 14:19 -0400, Dmitri Pal wrote:
  Cookie can be stored on the home directory of the user and user home
  directory can be NFS mounted so if we save anything important in the
  cookie the NFS root would be able to impersonate the user. It assumes
  that TGTs are not stored on the NFS in this case so replacing the TGT
  auth with fast session cookie auth would be a security issue.
  I hope I understand the issue correctly.
 
 We can store the the cookie in the ccache, so that we have it in the
 same place the TGT is. We shouldn't save it in the home, as it is
 insecure indeed.

I'd like to point out that this is a strong argument for adding the
SSSD/LDB Kerberos credential cache. It's unsafe to store the user's
credential cache in their home directory (because it may be an NFS mount
and therefore vulnerable to root on another machine).

However, the other common location for a credential cache is in /tmp,
which becomes an issue for systems running with pam_namespace or
sandboxing (where different processes have different views of the
contents of /tmp).

To avoid both of these situations, it might be best for us to store the
credential cache in SSSD.

For more information, see https://fedorahosted.org/sssd/ticket/652 and
https://bugzilla.redhat.com/show_bug.cgi?id=618689


signature.asc
Description: This is a digitally signed message part
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Summary of Session discussion

2011-05-26 Thread Dmitri Pal
On 05/26/2011 02:43 PM, Simo Sorce wrote:
 We need to extract the ticket first.
 You do not have direct access to the credential cache from within the
 browser so you wouldn't be able to do that for the WebUI anyway.
I was talking about the server side.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] Summary of Session discussion

2011-05-26 Thread Dmitri Pal
On 05/26/2011 02:43 PM, Simo Sorce wrote:
 You can limit it to have one cursor open per session at a time so you
  can use it as session global.
 Dangerous.

I have seen Adam's response.
This functionality is easily extensible. You can start with one and then
add hash.
I do not see a use case in near future that would require more than one
cursor to be open at a time per session.
I am just voting for less work here as it can be enhanced when we need
more than one.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] Summary of Session discussion

2011-05-26 Thread Adam Young

On 05/26/2011 04:56 PM, Dmitri Pal wrote:

On 05/26/2011 02:43 PM, Simo Sorce wrote:

You can limit it to have one cursor open per session at a time so you

can use it as session global.

Dangerous.


I have seen Adam's response.
This functionality is easily extensible. You can start with one and then
add hash.
I do not see a use case in near future that would require more than one
cursor to be open at a time per session.
I am just voting for less work here as it can be enhanced when we need
more than one.

The term Session global is a little weird.  If you mean that multiple 
requests in the same session can talk to the same cursor, then yes.  
Global implies multiple people can talk to it at once, and I do not mean 
that.


So long as the cursor is read only it will not be a problem to share.  
If the user does a write, or wants to see changes that were made by 
other people, they need to explicitly refresh the cursor.  As I said, 
getting this right requires thought, and should not be in the next release.


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] Summary of Session discussion

2011-05-26 Thread Dmitri Pal
On 05/26/2011 05:19 PM, Adam Young wrote:
 The term Session global is a little weird.  If you mean that
 multiple requests in the same session can talk to the same cursor,
 then yes.  Global implies multiple people can talk to it at once, and
 I do not mean that.

One cursor per session. The session is per user per connection. It is
one global cursor for a session not a hash table or list of different
cursors within a session. The latter IMO is not needed and an overhead.
If you can't have session per connection then you would have to do what
Simo suggests.

So this brings me to the next point: Are all connections from one host
started by the same user share the same session? If this is the case
then  uh ... bad ... than the hash is in fact needed. But this is
really scary...

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] Summary of Session discussion

2011-05-26 Thread Adam Young

On 05/26/2011 05:23 PM, Dmitri Pal wrote:

On 05/26/2011 05:19 PM, Adam Young wrote:

The term Session global is a little weird.  If you mean that
multiple requests in the same session can talk to the same cursor,
then yes.  Global implies multiple people can talk to it at once, and
I do not mean that.

One cursor per session. The session is per user per connection. It is
one global cursor for a session not a hash table or list of different
cursors within a session. The latter IMO is not needed and an overhead.
If you can't have session per connection then you would have to do what
Simo suggests.

So this brings me to the next point: Are all connections from one host
started by the same user share the same session? If this is the case
then  uh ... bad ... than the hash is in fact needed. But this is
really scary...

That is the usual implementation.  If I have a browser open, I want all 
of the requests made from that browser to go through the same session.  
If I have two browsers, say firefox and chrome, then they will have two 
different sessions.  HTTP does not maintain a connection across mutliple 
requests...with a few exceptions, mostly to streamline the download of 
graphics etc for a single page.  From a WebUI perspective, each JSON 
request would want to use the same session.


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] Summary of Session discussion

2011-05-26 Thread Rob Crittenden

Dmitri Pal wrote:

On 05/26/2011 05:19 PM, Adam Young wrote:

The term Session global is a little weird.  If you mean that
multiple requests in the same session can talk to the same cursor,
then yes.  Global implies multiple people can talk to it at once, and
I do not mean that.


One cursor per session. The session is per user per connection. It is
one global cursor for a session not a hash table or list of different
cursors within a session. The latter IMO is not needed and an overhead.
If you can't have session per connection then you would have to do what
Simo suggests.

So this brings me to the next point: Are all connections from one host
started by the same user share the same session? If this is the case
then  uh ... bad ... than the hash is in fact needed. But this is
really scary...



Each new connection gets its own cookie (e.g. you don't pass a cookie in 
then you get one once you authenticate).


To be honest, I was thinking about using the mod_session module but 
since we have only Apache 2.2.x it isn't available. We'll need to see 
what is available in the 2.x line.


rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel