You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by footh <fo...@yahoo.com> on 2004/11/21 01:59:31 UTC
SSL and form-based login
Through lots of research, I thought I had finally
figured out how to set up SSL with form-based login.
However, I still have a couple of outstanding issues.
SSL seems to be working fine, however, I don't believe
the login page is using SSL. The reason being is,
when I try to hit any other page on the site with SSL,
my browser invokes the certificate dialog box.
However, when the form-based login forces the redirect
to my custom login page, I don't get the certificate
dialog box. Here's a snippet the relevant parts of
web.xml (sorry if the formatting is bad):
<security-constraint>
<web-resource-collection>
<web-resource-name>Login pages</web-resource-name>
<url-pattern>/login/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>Form-Based uthentication</realm-name>
<form-login-config>
<form-login-page>/login/login.jsp</form-login-page>
<form-error-page>/login/logininvalid.jsp</form-error-page>
</form-login-config>
</login-config>
Another issue I have is if I have a "protected" page
that is using SSL, all links in the page default to
the SSL protocol even though those pages should just
be standard http. Might anyone know how to workaround
this? I've tried scouring the mailing lists on this
issue and I've actually found posts saying it is a
security risk to switch back to http.
Ex:
http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg61925.html
However, all these types of posts seem to be several
years old. Is this still a bad idea...to switch from
https to http?
Thanks
JF
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: SSL and form-based login
Posted by Peter Lin <wo...@gmail.com>.
the same rule still applies. that's what's just the reality of using
SSL and insuring security. A browser that is ssl compliant actually
should default to https. only way around that is to use a non-ssl
compliant browser.
peter
On Sat, 20 Nov 2004 16:59:31 -0800 (PST), footh <fo...@yahoo.com> wrote:
> Through lots of research, I thought I had finally
> figured out how to set up SSL with form-based login.
> However, I still have a couple of outstanding issues.
>
> SSL seems to be working fine, however, I don't believe
> the login page is using SSL. The reason being is,
> when I try to hit any other page on the site with SSL,
> my browser invokes the certificate dialog box.
> However, when the form-based login forces the redirect
> to my custom login page, I don't get the certificate
> dialog box. Here's a snippet the relevant parts of
> web.xml (sorry if the formatting is bad):
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Login pages</web-resource-name>
> <url-pattern>/login/*</url-pattern>
> </web-resource-collection>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
>
> <login-config>
> <auth-method>FORM</auth-method>
> <realm-name>Form-Based uthentication</realm-name>
> <form-login-config>
>
> <form-login-page>/login/login.jsp</form-login-page>
>
> <form-error-page>/login/logininvalid.jsp</form-error-page>
> </form-login-config>
> </login-config>
>
> Another issue I have is if I have a "protected" page
> that is using SSL, all links in the page default to
> the SSL protocol even though those pages should just
> be standard http. Might anyone know how to workaround
> this? I've tried scouring the mailing lists on this
> issue and I've actually found posts saying it is a
> security risk to switch back to http.
> Ex:
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg61925.html
>
> However, all these types of posts seem to be several
> years old. Is this still a bad idea...to switch from
> https to http?
>
> Thanks
> JF
>
> __________________________________
> Do you Yahoo!?
> Meet the all-new My Yahoo! - Try it today!
> http://my.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: problem with simultaneous query submissions
Posted by Satish Plakote <ps...@controlnet.co.in>.
here is my dopost method
// Code starts here
public void doPost(HttpServletRequest req,HttpServletResponse res) throws IOException, ServletException
{
System.out.println("Inside doPost");
String strQueryFlag =req.getParameter("new");
if(Integer.parseInt(strQueryFlag.toString())==NEW_QUERY)
{
System.out.println("New Search ..."+strQueryString);
Query query = null;
session.removeAttribute("BookObjects");
ArrayList arLstBookDetails = new ArrayList(10000);
try {
// Code to get data from Database or file
} catch (Exception e) {
e.printStackTrace();
}
try{
searchlog.println("--Creating objects--"+" "+session.getId()+" "+queryString);
StringBuffer strDesc = null;
StringBuffer strBookID = null;
StringBuffer strItemName = null;
StringBuffer strItemCode = null;
StringBuffer strPrice = null;
StringBuffer strPageID = null;
StringBuffer strBookName = null;
StringBuffer strUrl = null;
StringBuffer strImage = null;
for (// access data one by one from structure )
{
try{
// for each element
strDesc = // get the data and store it
strBookID = // get the data and store it
strItemName = // get the data and store it
strItemCode = // get the data and store it
strPrice = // get the data and store it
strPageID = // get the data and store it
strBookName = // get the data and store it
strUrl = // get the data and store it
strImage = // get the data and store it
strPageID = // get the data and store it
if(hBookFromLucene.containsKey(strBookID.toString()))
{
BookDetails BKDetails=(BookDetails)hBookFromLucene.get(strBookID.toString());
BKDetails.addPageDetails(strPageID,strPrice,strItemName,strDesc,strItemCode,strImage,strUrl);
}
else
{
BookDetails BKDetails= new BookDetails(strBookName,strBookID);
BKDetails.addPageDetails(strPageID,strPrice,strItemName,strDesc,strItemCode,strImage,strUrl);
hBookFromLucene.put(strBookID.toString(),BKDetails);
// adding objects to arraylist
arLstBookDetails.add(BKDetails);
}
// one more structure to store all objects
m_objallBookDetails.addBook(strBookName,strBookID,strPageID,strPrice,strItemName,strDesc,strItemCode,strImage,strUrl);
}catch(Exception e)
{
System.out.print("SearchDataBean: createBookObjects 1 "+e.getMessage());
e.printStackTrace();
}
} // end of for
strBookName = strBookID = strPageID = strPrice = strItemName = strDesc = strImage = strUrl = null;
}
searchlog.println("Putting data for session "+session.getId()+" "+arLstBookDetails.size());
// These two structures together can store 100000 data individually in session.
session.setAttribute("BookObjects",arLstBookDetails);
session.setAttribute("AllBookObj",m_objallBookDetails);
searchlog.println(" --- Completed--- "+arLstBookDetails.size());
}catch(Exception e)
{
System.out.println("SeachDataBean:getResultData: ");
e.printStackTrace();
}
}
// Code ends here
The reason i am storing the data is session is the the user is given a lot of filtering options and i don't want to go back to my
data source retrieve data and show.. all the filtering has to be done from objects in memory so thatit takes the minimum possible
time.
is the huge amount of data that i am storing that causes the problem ???
rgds
satish
-----Original Message-----
From: QM [mailto:qm300@brandxdev.net]
Sent: Tuesday, November 23, 2004 7:36 AM
To: Tomcat Users List
Subject: Re: problem with simultaneous query submissions
Please post a *new* message when writing to the list. Replying to an
old (unrelated) message confuses thread-aware mailers, which makes
your question harder to find (and thus answer).
On Tue, Nov 23, 2004 at 07:13:21AM +0530, Satish Plakote wrote:
: I have written a servlet that takes the input from user , queries the database and creates objects of the information that is
: recieved. These objects (approximatley 100000 ) are stored in the ArrayList which put in the session.using
session.putAttribute()
You're storing an ArrayList of 100,000 elements in the user session?
That's bound to cause problems... For one, think of the amount of data
being pulled back from the database, not to mention the memory used by
these objects.
You'd do well to limit the scope of the DB result list, even if that's
not (directly) related to the problem.
: While testing i noticed that if i open two browsers,with two different session ID, if submitted simultaneoulsy , one browser stops
: execution. i.e one instance of the servlet stops.. where as the other one proceeds fine..This happens for n broswers..
Do you open two different browsers, or two windows of the same browser?
: There is no problem with database connection as i have tested it.
Exactly how have you tested this?
: My servlet is only extending the HttpServlet.And my arraylist is not a class instance variable.each instance of the servlet is
: expected to keep its own copy..
Post the code, and someone here may be able to take a look at it.
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: problem with simultaneous query submissions
Posted by QM <qm...@brandxdev.net>.
Please post a *new* message when writing to the list. Replying to an
old (unrelated) message confuses thread-aware mailers, which makes
your question harder to find (and thus answer).
On Tue, Nov 23, 2004 at 07:13:21AM +0530, Satish Plakote wrote:
: I have written a servlet that takes the input from user , queries the database and creates objects of the information that is
: recieved. These objects (approximatley 100000 ) are stored in the ArrayList which put in the session.using session.putAttribute()
You're storing an ArrayList of 100,000 elements in the user session?
That's bound to cause problems... For one, think of the amount of data
being pulled back from the database, not to mention the memory used by
these objects.
You'd do well to limit the scope of the DB result list, even if that's
not (directly) related to the problem.
: While testing i noticed that if i open two browsers,with two different session ID, if submitted simultaneoulsy , one browser stops
: execution. i.e one instance of the servlet stops.. where as the other one proceeds fine..This happens for n broswers..
Do you open two different browsers, or two windows of the same browser?
: There is no problem with database connection as i have tested it.
Exactly how have you tested this?
: My servlet is only extending the HttpServlet.And my arraylist is not a class instance variable.each instance of the servlet is
: expected to keep its own copy..
Post the code, and someone here may be able to take a look at it.
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: SSL and form-based login
Posted by footh <fo...@yahoo.com>.
You mean something along the lines of having code on
the top of each page that checks the protocol and
redirects if necessary?
Or is it something a little lower level, perhaps in
the Tomcat configuration or similar to an ASAPI
filter?
Pardon my ignorance but Tomcat is all new to me...I
previously had only worked with IIS.
--- Carl Howells <ch...@janrain.com> wrote:
> footh wrote:
> > Now that I think about it, most (if not all) of my
> > non-SSL links are in include files. So, it is
> easy
> > enough to just place the full link in there. What
> > bugs me is I've seen other sites with relative
> links
> > on SSL pages that go to the non-SSL version (even
> when
> > you hover over the link and your browser claims it
> is
> > going to https). Using full links will be a pain
> too
> > for maintaining production and development
> > environments. Ugh...
> >
>
> It's easy enough to write a filter that notices
> https requests for
> resources that don't need to be protected, and
> redirects them to http.
> That kind of thing is certainly what the sites you
> mention are doing.
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tomcat-user-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: SSL and form-based login
Posted by Carl Howells <ch...@janrain.com>.
footh wrote:
> Now that I think about it, most (if not all) of my
> non-SSL links are in include files. So, it is easy
> enough to just place the full link in there. What
> bugs me is I've seen other sites with relative links
> on SSL pages that go to the non-SSL version (even when
> you hover over the link and your browser claims it is
> going to https). Using full links will be a pain too
> for maintaining production and development
> environments. Ugh...
>
It's easy enough to write a filter that notices https requests for
resources that don't need to be protected, and redirects them to http.
That kind of thing is certainly what the sites you mention are doing.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: SSL and form-based login
Posted by footh <fo...@yahoo.com>.
Great. Thank you both for your help.
I will do a bunch of research on Apache and try to get
my site similarly configured.
It definitely seems a lot easier than the options I
was considering.
Regards,
JF
--- Charles Daniel <da...@hotmail.com> wrote:
>
>
> >From: erh@swapsimple.com
> >Reply-To: "Tomcat Users List"
> <to...@jakarta.apache.org>
> >To: tomcat-user@jakarta.apache.org
> >Subject: Re: SSL and form-based login
> >Date: Wed, 24 Nov 2004 01:11:11 -0600
> >
> >On Tue, Nov 23, 2004 at 01:20:16PM -0800, footh
> wrote:
> > > > However, if the original page is http and the
> login
> > > > form is submitted
> > > > with https then it works fine. That seems
> like an
> > > > explicit constraint that
> > > > tomcat enforces, but I can't find where in the
> > > > authentication code it does
> > > > that. Of course, encrypting other requests
> and not
> > > > the login page is a
> > > > pretty stupid thing to do. :)
> > >
> > > You kind of lost me here...sorry if I'm being
> dense.
> > >
> > > So you are saying the only way to have a link
> within
> > > an SSL page go to non-SSL is either to hardcode
> the
> > > entire URL in the link or have all the links
> flow
> > > through a page that forces a redirect to the
> requested
> > > URL with non-SSL?
> >
> > uh.. what you just said is true, but it wasn't the
> point I
> >was making above. I was talking about the behavior
> of tomcat
> >with respect to how and when it saves the original
> url when
> >it needs to display the login form. For a new
> session, the
> >first request the browser makes to a protected
> causes that
> >url to be stored in the session, but that value
> isn't always
> >available to subsequent requests if the protocol is
> different.
> >
> > > Now that I think about it, most (if not all) of
> my
> > > non-SSL links are in include files. So, it is
> easy
> > > enough to just place the full link in there.
> What
> > > bugs me is I've seen other sites with relative
> links
> > > on SSL pages that go to the non-SSL version
> (even when
> > > you hover over the link and your browser claims
> it is
> > > going to https). Using full links will be a
> pain too
> > > for maintaining production and development
> > > environments. Ugh...
> >
> > as Carl Howells mentioned in a different message,
> this
> >could be done with a filter. Or you could write a
> javascript
> >function that runs when the body onload happens
> that goes and
> >and rewrites the urls of all the links on the page.
> (or if
> >you want to be evil, leaves the urls alone but sets
> onclick
> >handlers that redirect the browser directly.)
> >
> >eric
> >
>
>---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> tomcat-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> tomcat-user-help@jakarta.apache.org
> >
>
> You say some sites have links within their SSL pages
> that navigate to
> Non-SSL destinations. This can be accomplished by
> using the rewrite
> capabilities of some web servers. In my case I have
> used Apache's
> mod_rewrite to enforce those rules in the past.
>
> Let's say I have a page called registration.jsp
> under
> $CATALINA_HOME/webapps/myhost that I want to be SSL
> encrypted. One problem
> is that the user can bypass encryption by passing
> the URL
> http://www.myhost.com/registration.jsp. I need some
> way to force the user
> to use https for the registration.jsp page and
> others like it. Likewise, I
> want pages that don't require SSL to be rewritten as
>
> http://<something>/<something>.jsp. I can create
> Apache rewriting rules for
> either case.
>
> For a period of time I used Apache's mod_rewrite.
> The module compares the
> URL it receives to a list of wildcards that the
> admin defines in the rules
> section of the server's config file. In my case,
> any URL containing the
> word "register", would be rewritten as
> "https://<something>/register.jsp".
> So even if you had a relative page link like
> 'href="register.jsp"',
> mod_rewrite would convert it to the https equiv
> before the webserver
> processed it. In a sense this URL rewritting had
> the same effect as
> redirection.
>
> Also look into the MVC design archictecture for your
> applications. That is
> the Model, View, Controller architecture. Many
> sites designate one or more
> JSPs as a controller only page. This controller
> doesn't display any output.
> It's only function is to receive requests from the
> other JSPs on your site
> and forward them on to their proper destinations
> utilizing <jsp:forward>
> tags. In this way all of the discision making can
> be centralized into one
> controller. This simplifies the functions of the
> other JSPs by removing
> decision making logic from them. So page links,
> submits, imagemaps, inputs,
> selects and the like are simply passing requests to
> the controller JSP.
>
> Consider the following links:
>
> href="control.jsp?operation=login"
> href="control.jsp?operation=register"
>
> The control.jsp file will receive the request and
> examine the parameter
> called "operation". Embedded JSP scriptlettes will
> decide (usually via
> if..then..else logic) what to do next. Since
> operations like logging in and
> registering need to be secured, the JSP can use the
> HTTPResponse object to
> do a redirect to "https://<something>/login.jsp or
> "https://<something>/register.jsp.
>
> Just because your site uses a controller doesn't
> mean that the user has to
> obey the controller though. The user can still use
> URL manipulation to view
> any page on your site, thereby bypassing the
> controller. Thats why I
> recommend using mod_rewrite in conjunction with MVC.
> If an attempt is made
> to bypass your controller logic then the rewrite
> rules can catch them and
> rewrite them.
>
> Today, I use a virtual host in Apache to define my
> secure server. I find
> this to be a much more secure solution. Apache
> allows you to specify
> whether SSL is required or not for a virtual host.
> In this way your secure
> server will refuse Non-SSL connections. Because all
> my secure pages reside
> on my secure server (which is separate from the main
> server), then the only
> way to get to a secure page is through
> "https://secure.mydomain.com/<somejspfile>.jsp".
> Links back to my
> non-secure pages conform to
> "http://www.mydomain.com/<somejspfile>.jsp". Now
> how simple is that?
>
> The main server location -->
> $CATALINA_HOME/webapps/mainserver_app
> The secure server Location -->
> $CATALINA_HOME/webapps/secure_app
>
> This works out a lot better. I now have a
> designated server with its own
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: SSL and form-based login
Posted by Charles Daniel <da...@hotmail.com>.
>From: erh@swapsimple.com
>Reply-To: "Tomcat Users List" <to...@jakarta.apache.org>
>To: tomcat-user@jakarta.apache.org
>Subject: Re: SSL and form-based login
>Date: Wed, 24 Nov 2004 01:11:11 -0600
>
>On Tue, Nov 23, 2004 at 01:20:16PM -0800, footh wrote:
> > > However, if the original page is http and the login
> > > form is submitted
> > > with https then it works fine. That seems like an
> > > explicit constraint that
> > > tomcat enforces, but I can't find where in the
> > > authentication code it does
> > > that. Of course, encrypting other requests and not
> > > the login page is a
> > > pretty stupid thing to do. :)
> >
> > You kind of lost me here...sorry if I'm being dense.
> >
> > So you are saying the only way to have a link within
> > an SSL page go to non-SSL is either to hardcode the
> > entire URL in the link or have all the links flow
> > through a page that forces a redirect to the requested
> > URL with non-SSL?
>
> uh.. what you just said is true, but it wasn't the point I
>was making above. I was talking about the behavior of tomcat
>with respect to how and when it saves the original url when
>it needs to display the login form. For a new session, the
>first request the browser makes to a protected causes that
>url to be stored in the session, but that value isn't always
>available to subsequent requests if the protocol is different.
>
> > Now that I think about it, most (if not all) of my
> > non-SSL links are in include files. So, it is easy
> > enough to just place the full link in there. What
> > bugs me is I've seen other sites with relative links
> > on SSL pages that go to the non-SSL version (even when
> > you hover over the link and your browser claims it is
> > going to https). Using full links will be a pain too
> > for maintaining production and development
> > environments. Ugh...
>
> as Carl Howells mentioned in a different message, this
>could be done with a filter. Or you could write a javascript
>function that runs when the body onload happens that goes and
>and rewrites the urls of all the links on the page. (or if
>you want to be evil, leaves the urls alone but sets onclick
>handlers that redirect the browser directly.)
>
>eric
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
You say some sites have links within their SSL pages that navigate to
Non-SSL destinations. This can be accomplished by using the rewrite
capabilities of some web servers. In my case I have used Apache's
mod_rewrite to enforce those rules in the past.
Let's say I have a page called registration.jsp under
$CATALINA_HOME/webapps/myhost that I want to be SSL encrypted. One problem
is that the user can bypass encryption by passing the URL
http://www.myhost.com/registration.jsp. I need some way to force the user
to use https for the registration.jsp page and others like it. Likewise, I
want pages that don't require SSL to be rewritten as
http://<something>/<something>.jsp. I can create Apache rewriting rules for
either case.
For a period of time I used Apache's mod_rewrite. The module compares the
URL it receives to a list of wildcards that the admin defines in the rules
section of the server's config file. In my case, any URL containing the
word "register", would be rewritten as "https://<something>/register.jsp".
So even if you had a relative page link like 'href="register.jsp"',
mod_rewrite would convert it to the https equiv before the webserver
processed it. In a sense this URL rewritting had the same effect as
redirection.
Also look into the MVC design archictecture for your applications. That is
the Model, View, Controller architecture. Many sites designate one or more
JSPs as a controller only page. This controller doesn't display any output.
It's only function is to receive requests from the other JSPs on your site
and forward them on to their proper destinations utilizing <jsp:forward>
tags. In this way all of the discision making can be centralized into one
controller. This simplifies the functions of the other JSPs by removing
decision making logic from them. So page links, submits, imagemaps, inputs,
selects and the like are simply passing requests to the controller JSP.
Consider the following links:
href="control.jsp?operation=login"
href="control.jsp?operation=register"
The control.jsp file will receive the request and examine the parameter
called "operation". Embedded JSP scriptlettes will decide (usually via
if..then..else logic) what to do next. Since operations like logging in and
registering need to be secured, the JSP can use the HTTPResponse object to
do a redirect to "https://<something>/login.jsp or
"https://<something>/register.jsp.
Just because your site uses a controller doesn't mean that the user has to
obey the controller though. The user can still use URL manipulation to view
any page on your site, thereby bypassing the controller. Thats why I
recommend using mod_rewrite in conjunction with MVC. If an attempt is made
to bypass your controller logic then the rewrite rules can catch them and
rewrite them.
Today, I use a virtual host in Apache to define my secure server. I find
this to be a much more secure solution. Apache allows you to specify
whether SSL is required or not for a virtual host. In this way your secure
server will refuse Non-SSL connections. Because all my secure pages reside
on my secure server (which is separate from the main server), then the only
way to get to a secure page is through
"https://secure.mydomain.com/<somejspfile>.jsp". Links back to my
non-secure pages conform to "http://www.mydomain.com/<somejspfile>.jsp". Now
how simple is that?
The main server location --> $CATALINA_HOME/webapps/mainserver_app
The secure server Location --> $CATALINA_HOME/webapps/secure_app
This works out a lot better. I now have a designated server with its own
independent rules for my secure pages. This server has it own
<hostname.domain-name.sub-domain> and its own separate ip address. I just
love it.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: SSL and form-based login
Posted by er...@swapsimple.com.
On Tue, Nov 23, 2004 at 01:20:16PM -0800, footh wrote:
> > However, if the original page is http and the login
> > form is submitted
> > with https then it works fine. That seems like an
> > explicit constraint that
> > tomcat enforces, but I can't find where in the
> > authentication code it does
> > that. Of course, encrypting other requests and not
> > the login page is a
> > pretty stupid thing to do. :)
>
> You kind of lost me here...sorry if I'm being dense.
>
> So you are saying the only way to have a link within
> an SSL page go to non-SSL is either to hardcode the
> entire URL in the link or have all the links flow
> through a page that forces a redirect to the requested
> URL with non-SSL?
uh.. what you just said is true, but it wasn't the point I
was making above. I was talking about the behavior of tomcat
with respect to how and when it saves the original url when
it needs to display the login form. For a new session, the
first request the browser makes to a protected causes that
url to be stored in the session, but that value isn't always
available to subsequent requests if the protocol is different.
> Now that I think about it, most (if not all) of my
> non-SSL links are in include files. So, it is easy
> enough to just place the full link in there. What
> bugs me is I've seen other sites with relative links
> on SSL pages that go to the non-SSL version (even when
> you hover over the link and your browser claims it is
> going to https). Using full links will be a pain too
> for maintaining production and development
> environments. Ugh...
as Carl Howells mentioned in a different message, this
could be done with a filter. Or you could write a javascript
function that runs when the body onload happens that goes and
and rewrites the urls of all the links on the page. (or if
you want to be evil, leaves the urls alone but sets onclick
handlers that redirect the browser directly.)
eric
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: SSL and form-based login
Posted by footh <fo...@yahoo.com>.
--- erh@swapsimple.com wrote:
>
> > I guess I could set transport-guarantee tags to
> NONE
> > for every single non-SSL page. That just seems
> like a
> > bit of an administrative hassle as everytime I add
> a
> > new page (or rather, folder) I'd have to add the
> > appropriate transport tag.
>
> That won't work. The guarantee is a _minimum_
> guarantee.
> If you really want to switch back to non-SSL after
> login you
> need to jump through another explicit redirect.
>
> It seems almost like tomcat handles that
> automatically for
> you, except that the save request is not available
> to a http
> login form if the original request was https. i.e.
> if I point my
> browser at "https://foo.com/some_protected_page",
> then simulate a
> redirect by going to
> "http://foo.com/unprotectedlogin.html" and submit
> the form (which would be
> "http://foo.com/j_security_check"),
> it complains about the "time allowed for the login
> process has been exceeded".
> However, if the original page is http and the login
> form is submitted
> with https then it works fine. That seems like an
> explicit constraint that
> tomcat enforces, but I can't find where in the
> authentication code it does
> that. Of course, encrypting other requests and not
> the login page is a
> pretty stupid thing to do. :)
You kind of lost me here...sorry if I'm being dense.
So you are saying the only way to have a link within
an SSL page go to non-SSL is either to hardcode the
entire URL in the link or have all the links flow
through a page that forces a redirect to the requested
URL with non-SSL?
Now that I think about it, most (if not all) of my
non-SSL links are in include files. So, it is easy
enough to just place the full link in there. What
bugs me is I've seen other sites with relative links
on SSL pages that go to the non-SSL version (even when
you hover over the link and your browser claims it is
going to https). Using full links will be a pain too
for maintaining production and development
environments. Ugh...
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
problem with simultaneous query submissions
Posted by Satish Plakote <ps...@controlnet.co.in>.
hi,
i am developing a search engine for my small database.
I have written a servlet that takes the input from user , queries the database and creates objects of the information that is
recieved. These objects (approximatley 100000 ) are stored in the ArrayList which put in the session.using session.putAttribute()
While testing i noticed that if i open two browsers,with two different session ID, if submitted simultaneoulsy , one browser stops
execution. i.e one instance of the servlet stops.. where as the other one proceeds fine..This happens for n broswers..
There is no problem with database connection as i have tested it.
My servlet is only extending the HttpServlet.And my arraylist is not a class instance variable.each instance of the servlet is
expected to keep its own copy..
I am not able to figure out what is the problem..
Pls help..
rgds
satish
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: SSL and form-based login
Posted by er...@swapsimple.com.
On Mon, Nov 22, 2004 at 08:21:11AM -0800, footh wrote:
> On another note, once I'm in a page that is set to use
> SSL all relative links within that page continue to
> use SSL even though I would rather they be non-SSL.
> Is there an easy way to prevent that other than
> hardcoding absolute URLs in all the non-SSL links?
nope. that's just how relative links work.
The "https://" part is treated no differently than the
"www.somewhere.com" portion.
> I guess I could set transport-guarantee tags to NONE
> for every single non-SSL page. That just seems like a
> bit of an administrative hassle as everytime I add a
> new page (or rather, folder) I'd have to add the
> appropriate transport tag.
That won't work. The guarantee is a _minimum_ guarantee.
If you really want to switch back to non-SSL after login you
need to jump through another explicit redirect.
It seems almost like tomcat handles that automatically for
you, except that the save request is not available to a http
login form if the original request was https. i.e. if I point my
browser at "https://foo.com/some_protected_page", then simulate a
redirect by going to "http://foo.com/unprotectedlogin.html" and submit
the form (which would be "http://foo.com/j_security_check"),
it complains about the "time allowed for the login process has been exceeded".
However, if the original page is http and the login form is submitted
with https then it works fine. That seems like an explicit constraint that
tomcat enforces, but I can't find where in the authentication code it does
that. Of course, encrypting other requests and not the login page is a
pretty stupid thing to do. :)
eric
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: SSL and form-based login
Posted by footh <fo...@yahoo.com>.
Thanks for the help. I see what you are saying about
the redirection to the login page not being a true
redirect. I'll give your method a shot and see how it
turns out. I can't believe this issue hasn't been
resolved before but I can't seem to find it via a
search on the archives.
On another note, once I'm in a page that is set to use
SSL all relative links within that page continue to
use SSL even though I would rather they be non-SSL.
Is there an easy way to prevent that other than
hardcoding absolute URLs in all the non-SSL links?
I guess I could set transport-guarantee tags to NONE
for every single non-SSL page. That just seems like a
bit of an administrative hassle as everytime I add a
new page (or rather, folder) I'd have to add the
appropriate transport tag.
--- erh@swapsimple.com wrote:
> On Sun, Nov 21, 2004 at 10:53:52AM -0800, footh
> wrote:
> > The URL in the browser is the URL of the protected
> > page I'm trying to access. So, for example if
> > /test/test.jsp is protected by forms-login and I
> click
> > a link to that page, /test/test.jsp will be the
> URL in
> > the browser, but the login page will appear on the
> > screen.
> Well, that sounds like you're not getting an actual
> redirect
> to the login page. Unless you do that, the brower
> never sends
> another request, so you stay in http mode.
> According to the
> servlet spec it's not supposed to do a redirect.
> Since it's not a redirect, the urls specified in
> login-config don't
> get matched against a security constraint.
> If they did, it'd be hard not to create loops.
> e.g.:
> access to somepage.jsp triggers security-constraint
> on *.jsp requiring
> realm foo.
> login-config is triggered to allow tomcat to figure
> out which realm the
> user is in
> url for that is login.jsp, security-constraint is
> triggered, etc...
> That seems to make the automatic form login not all
> that useful
> for ssl stuff, at least not at first glance. A
> solution might be to
> point your login-config url at a page that does an
> immediate redirect to the
> actual login page.
>
> i.e.:
> define a security constraint that forces ssl and
> applies only to login.jsp
> no realm! since there's an explicit redirect we
> don't want to create a loop.
> define another security constraint that specifies a
> realm and applies
> to everything else.
> setup login-config to point to redirect.jsp
> redirect.jsp does an immediate c:redirect to
> login.jsp
> login.jsp works like normal. (j_security_check form
> and all)
>
> Well, that's how I'm hoping it would work. That
> depends on whether
> the redirect that redirect.jsp does, and the extra
> get the browser
> does, will cause tomcat to clear out it's original
> stored url.
> It seemed to work that way with a quick test I just
> did, but I'm
> not entirely sure I did it right.
>
> eric
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tomcat-user-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: SSL and form-based login
Posted by er...@swapsimple.com.
On Sun, Nov 21, 2004 at 10:53:52AM -0800, footh wrote:
> The URL in the browser is the URL of the protected
> page I'm trying to access. So, for example if
> /test/test.jsp is protected by forms-login and I click
> a link to that page, /test/test.jsp will be the URL in
> the browser, but the login page will appear on the
> screen.
Well, that sounds like you're not getting an actual redirect
to the login page. Unless you do that, the brower never sends
another request, so you stay in http mode. According to the
servlet spec it's not supposed to do a redirect.
Since it's not a redirect, the urls specified in login-config don't
get matched against a security constraint.
If they did, it'd be hard not to create loops. e.g.:
access to somepage.jsp triggers security-constraint on *.jsp requiring
realm foo.
login-config is triggered to allow tomcat to figure out which realm the
user is in
url for that is login.jsp, security-constraint is triggered, etc...
That seems to make the automatic form login not all that useful
for ssl stuff, at least not at first glance. A solution might be to
point your login-config url at a page that does an immediate redirect to the
actual login page.
i.e.:
define a security constraint that forces ssl and applies only to login.jsp
no realm! since there's an explicit redirect we don't want to create a loop.
define another security constraint that specifies a realm and applies
to everything else.
setup login-config to point to redirect.jsp
redirect.jsp does an immediate c:redirect to login.jsp
login.jsp works like normal. (j_security_check form and all)
Well, that's how I'm hoping it would work. That depends on whether
the redirect that redirect.jsp does, and the extra get the browser
does, will cause tomcat to clear out it's original stored url.
It seemed to work that way with a quick test I just did, but I'm
not entirely sure I did it right.
eric
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: SSL and form-based login
Posted by footh <fo...@yahoo.com>.
The URL in the browser is the URL of the protected
page I'm trying to access. So, for example if
/test/test.jsp is protected by forms-login and I click
a link to that page, /test/test.jsp will be the URL in
the browser, but the login page will appear on the
screen.
I am sure I didn't already accept the certificate as
after I hit the login page, instead of logging in, I
type in the URL to the home page but use https and the
certificate dialog box comes up. Then I press cancel,
and repeat the process, and once again the certificate
box comes up.
--- erh@swapsimple.com wrote:
> On Sat, Nov 20, 2004 at 04:59:31PM -0800, footh
> wrote:
> > SSL seems to be working fine, however, I don't
> believe
> > the login page is using SSL. The reason being is,
> > when I try to hit any other page on the site with
> SSL,
> > my browser invokes the certificate dialog box.
> > However, when the form-based login forces the
> redirect
> > to my custom login page, I don't get the
> certificate
> > dialog box. Here's a snippet the relevant parts
> of
> > web.xml (sorry if the formatting is bad):
>
> Does your browser url say https? If so, it should
> be in
> secure mode. Are you sure you didn't already accept
> the
> certificate during your browser session? Try
> sniffing your
> network traffic to make sure though.
>
> > However, all these types of posts seem to be
> several
> > years old. Is this still a bad idea...to switch
> from
> > https to http?
>
> That depends on what you're trying to guarantee.
> If you're just trying to protect the password
> information that is
> entered during login, then switching back to http is
> ok.
>
> However, since the subsequent traffic is
> unencrypted an attacker could
> observe the sessionid that is used and hijack the
> session, often without
> any immediate indication of a problem from the
> user's point of view.
> If you're paranoid you'll want to do things like
> make sure a _new_
> sessionid is created once you jump into https mode,
> and cause any non-https
> access using that new sessionid to instantly
> invalidate the session.
> (although as soon as there's any non-encrypted
> access with a given
> sessionid the attacker can theoretically race your
> session-killing request
> and create some havoc)
>
> For the slightly less paranoid, identifying the
> sensitive portions
> of your application and gating them with another
> https enabled password
> page might be reasonable.
>
> It all depends on how worried you are and how much
> effort you
> think someone will put into circumventing your
> security.
>
> eric
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tomcat-user-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: SSL and form-based login
Posted by er...@swapsimple.com.
On Sat, Nov 20, 2004 at 04:59:31PM -0800, footh wrote:
> SSL seems to be working fine, however, I don't believe
> the login page is using SSL. The reason being is,
> when I try to hit any other page on the site with SSL,
> my browser invokes the certificate dialog box.
> However, when the form-based login forces the redirect
> to my custom login page, I don't get the certificate
> dialog box. Here's a snippet the relevant parts of
> web.xml (sorry if the formatting is bad):
Does your browser url say https? If so, it should be in
secure mode. Are you sure you didn't already accept the
certificate during your browser session? Try sniffing your
network traffic to make sure though.
> However, all these types of posts seem to be several
> years old. Is this still a bad idea...to switch from
> https to http?
That depends on what you're trying to guarantee.
If you're just trying to protect the password information that is
entered during login, then switching back to http is ok.
However, since the subsequent traffic is unencrypted an attacker could
observe the sessionid that is used and hijack the session, often without
any immediate indication of a problem from the user's point of view.
If you're paranoid you'll want to do things like make sure a _new_
sessionid is created once you jump into https mode, and cause any non-https
access using that new sessionid to instantly invalidate the session.
(although as soon as there's any non-encrypted access with a given
sessionid the attacker can theoretically race your session-killing request
and create some havoc)
For the slightly less paranoid, identifying the sensitive portions
of your application and gating them with another https enabled password
page might be reasonable.
It all depends on how worried you are and how much effort you
think someone will put into circumventing your security.
eric
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org