Birger Burkhardt wrote on 2/28/12 7:48 AM:
Hi Francisco,
i am not quite sure, if it could be done using existing classes/modules. Can
you please have a look
at the following both links. Are you sure, i have to implement the storage of
the passwod in a
memcached server?
Hi Francisco,
i am not quite sure, if it could be done using existing
classes/modules. Can you please have a look
at the following both links. Are you sure, i have to implement the
storage of the passwod in a
memcached server?
Hi Birger,
Once you've authenticated with LDAP, or with any backend, it is important that
you store the session information somewhere.. Some people use a database,
memcached, tmp file, or any other method.
That way, when the client comes with the next request, he will offer a cookie
that can
Hi Francisco,
thank you for your reply. I already use sessions (FastMmap for Storage and
Cookies for State). I can login to the GUI via my LDAP credentials. But the
problem is: every further request has to be done with my personal
credentials. Therefore the password should be stored somewhere
You don't need to store the password... You just need to have a session id that
has a short lifetime while you browse..
You can tie that session id with an ip address for additional security .
Francisco
On Feb 27, 2012, at 1:06 PM, Birger Burkhardt sysde...@googlemail.com wrote:
Hi
Hi Francisco,
sorry, but i think we are not talking about the same.
1.) The GUI uses its own LDAP Bind credentals for Directory search purposes.
2.) On user login, the catalyst app binds to LDAP via the credentials of
the user. On success, session is established, user is logged in. So far so
good
I see what the problem is now.
I would store it locally using a Memcached server, and would use the session_id
as the key..
That way you can use the auto-expire feature, thus functioning like a key-ring.
In case you have multiple servers handling the requests, they can always
connect to the
Birger Burkhardt wrote on 2/24/12 7:22 AM:
After successful authentication, all further request
should be executed via the credentials of the logged in user.
are you somehow storing those credentials so that they persist over the life of
the session? The LDAP authn plugin does not do that
