On 11/19/2003 03:58 AM Henrik Bentel wrote:
Had an application which had 3 different types of users:
One group should be authenticated using https only to protect password,
then switch to http, but sometimes switch back to https again.
This is my main requirement.
Ideally what I would like to
Hello
On 11/17/2003 06:32 AM Andrew Mottaz wrote:
Option 1 is unacceptable -- the overhead of having all of these connections
encrypted is not a viable option.
What are the 'overheads' in using SSL? How much harder does the server have
to work, and - in practice - what sort of performance
On 11/18/2003 07:45 AM Bill Barker wrote:
You'll have to go back at least two years to get the tomcat-dev
discussion ;-).
I had another search for it but can't find anything. Ploughing thro the
whole list of threads doesn't fit in my schedule unfortunately. I guess
I'm just going to have sit on
Harry,
Option 1 is unacceptable -- the overhead of having all of these connections
encrypted is not a viable option.
What are the 'overheads' in using SSL? How much harder does the server have
to work, and - in practice - what sort of performance impact does this have?
I don't have any numbers,
Hello Chris
Thank you so much for the feed-back. It is a very useful insight, and much
appreciated!
Kind regards
Harry Mantheakis
London, UK
Harry,
Option 1 is unacceptable -- the overhead of having all of these connections
encrypted is not a viable option.
What are the 'overheads' in
I ran into this issue about 2 years ago and posted the same question.
Had an application which had 3 different types of users:
One group should be authenticated using https only to protect password,
then switch to http, but sometimes switch back to https again.
Other group should be
On 11/17/2003 06:32 AM Andrew Mottaz wrote:
http://nagoya.apache.org/bugzilla. However, there aren't very many
developers who like the idea of allowing you to hang yourself :).
Thanks much for the tip -- I have to disagree about this not being a
necessary change. There are plenty of apps where
: 17 November 2003 05:32
To: Tomcat Users List
Subject: Re: https -- http session problem
http://nagoya.apache.org/bugzilla. However, there aren't very many
developers who like the idea of allowing you to hang yourself :).
Thanks much for the tip -- I have to disagree about this not being
On 11/17/2003 06:32 AM Andrew Mottaz wrote:
http://nagoya.apache.org/bugzilla. However, there aren't very many
developers who like the idea of allowing you to hang yourself :).
Thanks much for the tip -- I have to disagree about this not being a
necessary change. There are plenty of apps
On 11/17/2003 05:15 PM Andrew Mottaz wrote:
Also, as far as I can see, the java community has decided that once you
start a secure session, you should stay in a secure session, for various
security reasons. Are you doing a secure login and then redirecting back
to http afterwards?
Imagine the
I read this post and have a question...and maybe I'm not understanding
https correctly, but why is your login PAGE secure? I wouldn't care if
someone sees an empty page with a prompt for the username and password.
The post should be secure though... In other words... can't you have a
page
You are correct -- it is a user perception issue -- that makes my argument a
bit less persuasive -- but -- I still say give the developer control.
Andrew
I read this post and have a question...and maybe I'm not understanding
https correctly, but why is your login PAGE secure? I wouldn't care
On 11/17/2003 11:58 PM Kevin Williams wrote:
I read this post and have a question...and maybe I'm not understanding
https correctly, but why is your login PAGE secure? I wouldn't care if
someone sees an empty page with a prompt for the username and password.
The post should be secure though...
Adam Hardy [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On 11/17/2003 05:15 PM Andrew Mottaz wrote:
Also, as far as I can see, the java community has decided that once you
start a secure session, you should stay in a secure session, for various
security reasons. Are you doing a
Why is this the case, and where does one put in an enhancement request? I
can see the argument for wanting the OPTION of forcing secure connections or
losing your session, but to not even have the option of having the session
cookie be insecure doesn't make much sense.
I understand the potential
Andrew Mottaz [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Why is this the case, and where does one put in an enhancement request?
I
can see the argument for wanting the OPTION of forcing secure connections
or
losing your session, but to not even have the option of having the
http://nagoya.apache.org/bugzilla. However, there aren't very many
developers who like the idea of allowing you to hang yourself :).
Thanks much for the tip -- I have to disagree about this not being a
necessary change. There are plenty of apps where people browse without
a secure
Andrew Mottaz [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I've run into the problem where a session cookie gets lost when you
start on http and move to https. The reason seems to be that
'secure=true' is set on the session cookie when you start on https,
preventing the cookie
I've run into the problem where a session cookie gets lost when you
start on http and move to https. The reason seems to be that
'secure=true' is set on the session cookie when you start on https,
preventing the cookie from being passed to the http page.
I found the following in the archives:
19 matches
Mail list logo
