Bohdan Linda wrote:
On Thu, May 15, 2008 at 05:40:49PM +0200, Steve Manes wrote:
I keep the user's login credentials in a TripleDES-encrypted,
non-persistent cookie, separate from session data.
This is the approach I am/will be heading to. Having the cookie with login
and password encrypted on
Hello,
thank you everyone for the answers. I went through and I forgot add one
thing. The web-app is frontend, thus basically PL/PGSQL launcher and all
changes are audited, so common login is unwelcome.
On Thu, May 15, 2008 at 05:40:49PM +0200, Steve Manes wrote:
> I keep the user's login crede
Steve Crawford wrote:
You can make some modest security improvements by storing things such as
the browser identification and IP address in the session data and
verifying it on each request but IP verification fails if the user is
behind a proxy like AOL's where each request may come from a di
Bohdan Linda wrote:
The frontend is web based so it is stateless; it is connecting to database
on every get/post. There is also a requirement that the user is
transparently logged in for some period of time.
Tha most easy way is to store login credentials into the session. The
drawback is that s
[EMAIL PROTECTED] wrote:
...
By the way, this is an *intra*net-solution, and we don't have hackers
in our staff, I hope...
Cross your fingers - most compromises come from inside the firewall.
Cheers,
Steve
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
Bohdan Linda wrote:
Hello,
I have the following problem. A multiuser app has authentization and
authorization done based on pgsql.
The frontend is web based so it is stateless; it is connecting to database
on every get/post. There is also a requirement that the user is
transparently logged in f
In our web-based-solution (PHP) the database credentials (username and password) are encrypted and stored by PHP as session-Variables.Yes, there is the risk, they could be read by someone, who has access to the apache-sessions-directory, but this user also must have access to the php-scripts with
You could try to have a function in your application that encrypts the
connection string and store it in a session variable. When you need it
you decrypted from the session variables. Session variables are stored
as files on the server, therefore the risk is not as high.
Just a thought.
Fer
Hi Bohdan,
Is your web applications for use with PostgreSQL server administration
where you would like users to supply their login credentials for
PostgreSQL so that their actions within the db can be limited by the
fine gain privileges assigned to them?
If it is not then you may want to mayb
Hello,
I have the following problem. A multiuser app has authentization and
authorization done based on pgsql.
The frontend is web based so it is stateless; it is connecting to database
on every get/post. There is also a requirement that the user is
transparently logged in for some period of time
10 matches
Mail list logo
