Re: Basic and Form Authentication
Hi all, Winners never quit and quitters never win See. http://marc.info/?l=tomcat-userm=126047599208053w=2 Thanks for the assistance!!! Tony Anthony Jay wrote: yes, I was aware of this, as mentioned on a previous mail, but as its neither production ready nor complete it would be a huge risk. I am beginning to think that I am attempting the impossible... After several weeks banging my head against a wall (I have a sore neck) I am giving this one more day then giving up ;-( On this list, we dislike it when people give up. Give us all a feeling of failure. Come on, a bit of perseverance may be the key. What about my other post of yesterday, on the thread : Re: Contexts and Path and Authentication ? Does at least the initial description match what you would need ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Contexts and Path and Authentication
Excellent. Now I have an elegant plan B in case my current apache-mod_auth_mysql-tomcat-form-based-authentication solution proves impractical. http://marc.info/?l=tomcat-userm=126047599208053w=2 Regards, Tony Christopher Schultz wrote: securityfilter (http://securityfilter.sourceforge.net) can be tricked into doing this. Although the standard operating procedure is to map sf to all URLs (i.e. url-pattern/*/url-pattern), one can choose to map it to different patterns and deploy it /twice/: filter filter-nameSecurity Filter BASIC/filter-name filter-classorg.securityfilter.filter.SecurityFilter/filter-class init-param param-nameconfig/param-name param-value/WEB-INF/securityfilter-basic.xml/param-value /init-param /filter filter filter-nameSecurity Filter FORM/filter-name filter-classorg.securityfilter.filter.SecurityFilter/filter-class init-param param-nameconfig/param-name param-value/WEB-INF/securityfilter-form.xml/param-value /init-param /filter ... I did not know that securityfilter handled both Basic and Form authentication. Is that recent ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Contexts and Path and Authentication
What's the problem with doing: /xml/-- basic auth /xml/secure/ -- basic auth TonyI cannot change URL as this is a working application and XML consumers must notice no difference. Then this bit of the app can be deployed as xml.war and the other as ROOT.war. Modifying your URL namespaces would seem to be a logical improvement. TonyNo doubt about that but this is what I have to work with/Tony If needs be, you can redirect /secure/xml/ requests from the ROOT app to the xml app. TonyAs mentioned I'm having difficulty with UrlRewriteFilter and Tomcat 6/Tony Thanks for the input, all ideas are most welcome! Tony /Tony On 09/12/2009 21:07, Anthony Jay wrote: Hi All, I am having tremendous difficulty configuring contexts on tomcat. I've had to split my perfectly working application into two applications as the jsp now requires Form based authentication and the XML components require Http Basic authentication as before. As I've learned the very hard way I cannot do both within the same application without writing my own security plumbing. So I've taken peoples advice and made one war file formauth.war with all jsp and related servlets which uses form based auth and also created basicauth.war which contains all xml servlet configuration, I put the common libs into tomcat/lib directory (to handle Statics and singletons and DB stuff) Two apps, two authentication mechanisms. Messy but I could see no other way. My jsps etc are contained on the path /secure/xxx and /secure/yyy as well as /public/* But my XML URL pattern for servlets is /secure/xml/* and /xml/* which are declared in web.xml Individually each war when deployed seem to work fine except for the uri/path configuration. i.e. URL prepended with /formauth/ or /basicauth/ prefixes. Currently this works: /formauth/secure/yyy --Form based auth /formauth/secure/xxx --Form based auth /formauth/public/ --Form based auth /basicauth/secure/xml/ --basic auth /basicauth/xml/ --basic auth etc. Which is not what I want, the application must work as before. /secure/yyy --Form based auth /secure/xxx --Form based auth /public/ --Form based auth /secure/xml/ --basic auth /xml/ --basic auth What's the problem with doing: /xml/-- basic auth /xml/secure/ -- basic auth Then this bit of the app can be deployed as xml.war and the other as ROOT.war. Modifying your URL namespaces would seem to be a logical improvement. If needs be, you can redirect /secure/xml/ requests from the ROOT app to the xml app. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
yes, I was aware of this, as mentioned on a previous mail, but as its neither production ready nor complete it would be a huge risk. I am beginning to think that I am attempting the impossible... After several weeks banging my head against a wall (I have a sore neck) I am giving this one more day then giving up ;-( Regards, Tony Hi. I got some (as yet partial) answers on this on the Apache httpd forum. Check out this : http://httpd.apache.org/docs/trunk/mod/mod_auth_form.html In summary, and subject to more confirmation by the Apache developers : A series of new Apache modules is due to appear in Apache 2.4 (the next production release version). They include mod_session and mod_auth_form, which should provide a generic form-based authentication framework. These modules are currently available in the test version of Apache (2.34). I do not know yet if they are, or can be, back-ported for Apache 2.2.14, the current production version. But all in all, it seems that this provides the as-yet missing standard form-based authentication framework which would be needed by the original poster on this thread, if he wanted to resolve his issue by using an httpd front-end (which he uses anyway for other purposes right now). Well, at least it would be a start. It remains to be seen in detail how one would set this up under Apache httpd. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Contexts and Path and Authentication
SOLVED Also the issue with Multiple Authentication Mechanisms My head is sore from banging it against a wall but I THINK that I have come up with a rather elegant solution. Well its a bit obvious in one way but I suppose I had to go through all the pain first. There was alot of pain. Just to reiterate my issue : How to get Tomcat to use Http basic and http form authentication in same application. I have /secure/xml/** servlets that need basic auth /xml/** servlets that need NO auth /secure/.jsp that need FORM auth /ssl/xxx.jsp that needs NO AUTH / standard web content that is public etc. All working together as ONE application This stemmed from an app that was using http basic and the user/jsp stuff had to be converted to Form based auth for security reasons and obviously the b2b xml stuff could not change URLS or auth mechanisms being hard coded on the client side in our customers apps. SOLUTION apache SSL termination mod_auth_mysql http basic ONLY on servlet urls using LocationMatch directives mod_jk forwarding jsp and servlets to tomcat tomcat configured for FORM based auth ignored unprotected content. Application deployed as ROOT.war (no messing around with contexts or path) So the apache acts as a http filter on servlets that require http basic and ignores everything else. Tomcat uses form based authn to protected all jsp pages that require it and ignores those that dont. Rather happy with this solution as I can offload images/etc to apache, I get loadbalancing from mod_jk and high availability. Im sure there are a few speedbumps along the way but 90% sure this will work. (Note the 10% reserved for experience) Tony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Contexts and Path and Authentication
Hi All, I am having tremendous difficulty configuring contexts on tomcat. I've had to split my perfectly working application into two applications as the jsp now requires Form based authentication and the XML components require Http Basic authentication as before. As I've learned the very hard way I cannot do both within the same application without writing my own security plumbing. So I've taken peoples advice and made one war file formauth.war with all jsp and related servlets which uses form based auth and also created basicauth.war which contains all xml servlet configuration, I put the common libs into tomcat/lib directory (to handle Statics and singletons and DB stuff) Two apps, two authentication mechanisms. Messy but I could see no other way. My jsps etc are contained on the path /secure/xxx and /secure/yyy as well as /public/* But my XML URL pattern for servlets is /secure/xml/* and /xml/* which are declared in web.xml Individually each war when deployed seem to work fine except for the uri/path configuration. i.e. URL prepended with /formauth/ or /basicauth/ prefixes. Currently this works: /formauth/secure/yyy --Form based auth /formauth/secure/xxx --Form based auth /formauth/public/ --Form based auth /basicauth/secure/xml/ --basic auth /basicauth/xml/ --basic auth etc. Which is not what I want, the application must work as before. /secure/yyy --Form based auth /secure/xxx --Form based auth /public/ --Form based auth /secure/xml/ --basic auth /xml/ --basic auth I need to remove the /formauth/ and /basicauth/ directories and my pain will subside. From everything that I have read this SHOULD be possible when configuring the context element. My issue now is that trying to overlap the contexts will not work for me. I can only get one war to work at at time (as default context) using Server.xml Context docBase=formauth path=/ when war is deployed in the webapps folder. I have tried Context docBase=formauth path=secure/xxx/ and many different combinations but I can never remove the /formauth/ or /basicauth/ prefixes except when one is set as default, but then I cannot configure the other context. A little advice here should go a long way as I've read http://tomcat.apache.org/tomcat-6.0-doc/config/context.html and related pages and posts about a fifty times as well as sample setups. I'm really pulling my hair out now.this is taking me waay too long. There are many brownie points going for this one. Tony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Contexts and Path and Authentication
Many thanks Chuck and Ken for the tip. I am surprised that the solution is a 'hack' rather than configuration, but kinda glad that I wasn't losing my marbles. URL Rewriting is probably going to be the easiest way out, I am considering using mod_jk on the apache side so I could get away with using it there, but its always nice to 'hit' tomcat directly and get the same result. maybe someday Ill write a patch/plugin/filter/gizmo that will allow form and basic on same app and present it to the world... Then again form/basic auth on apache side isnt too far away. I feel like I am hitting a brick wall with my head more often than I should be (Any other tips welcome!) Regards, Tony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Contexts and Path and Authentication
Hi, FYI just hit another stumbling block which may be of interest to other users. UrlRewriteFilter will not forward any of my requests, even to the sample demo rule for /rewrite-status/ itself! It will, however, redirect perfectly well (when type is changed to type=redirect) meaning that I have installed the filter properly. Other persons seem to be having issues with UrlRewriteFilter and Tomcat 6 (see the google groups posts for some unresolved issues) In addition UrlRewriteFilter cannot forward outside of its application context without changing Context configuration. http://tinyurl.com/3q9fa9 Interesting. Tony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
Thanks all for your comments, I do appreciate the expert assistance. As I suspected I will have to split the webapp into seperate apps based on the authentication method required. Seems like a funny way to arrange an application but such is life. As for cross application communication I will have to revisit our own code to see if there are static/singleton services that can be re-engineered and decoupled. In terms of hacking code to fudge application access, this would be low on my list, I would not like to alter or maintain security related code. Many thanks again. (Much head scratching to continue) Tony -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony, On 11/30/2009 4:53 AM, Anthony Jay wrote: Is is possible to have an application that serves content protected by BASIC and FORM based auth? As Mark points out, the servlet spec says not in the same webapp. Tomcat implements the servlet specification and no more, so you are out of luck, there. I could deploy seperate apps for each type but I would then lose access to application specific information e.g. Singletons and Statics, which will cause big problems. I would strongly advise you to separate your webapps: one webapp for your XML-based API and the other for human interaction. Don't forget that your human UI could make use of the XML API behind the scenes. This is typically called drinking your own Cool-Aid. If it's possible for you to do so, you could put your shared singleton/static classes into a shared ClassLoader. What kinds of things are you using that you would need to share across webapps? Could those things be converted into services that both webapps could share? Note that an XML service whose URL contains a jsessionid parameter will be associated with the indicated session. You could use such a URL to avoid the FORM authentication (but getting the session id is, of course, an issue unresolved by this). Finally, you could go out on your own and implement your own authentication mechanism. Securityfilter is a simple, filter-based authentication and authorization mechanism that you could hack-up to do this type of thing. Actually, you could use it out-of-the-box and just use a Filter configured /in front/ of it to trick sf into trusting a Principal configured by your Filter (which comes from the request's HTTP AUTH data). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUHsEACgkQ9CaO5/Lv0PD/jACeKCyBSKRnZtnso5EzEPROUMXO i74An09m3QZY0GTl47KplbdCSu/NG1wr =t+z3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
Hi, Thanks for the great advice. On placing singletons etc in jar libraries in tommcat /lib directory, that would be a very simple hack that could keep code pretty much as is. Thank you for that suggestion, it may well be a runner, I didnt think that was possible. In terms of fronting everything with apache, I am currently doing this already via mod_jk (loadbalancing to 2 tomcats), although I might use mod_proxy_ajp in future as it is now bundled with apache2. However, I could not find any viable implementation for form based authentication, although there is one in the pipeline but may not be available in a stable form for many months to come. That was a big disappointment! Many thanks, Tony Peter Crowther wrote: 2009/12/1 Anthony Jay anthony...@fastmail.fm: As for cross application communication I will have to revisit our own code to see if there are static/singleton services that can be re-engineered and decoupled. This may be one of the few appropriate times where you may want to put code for the singletons (and all the classes that might be referenced by your singletons) in common/lib. It's not an ideal solution, but it may save you considerable effort as those classes will then be loaded by a single classloader, rather than the per-webapp classloaders. Or then, this may be a case where you want to explore front-ending these applications with an Apache httpd server, linked to Tomcat via an AJP connector. There is considerably more flexibility in Apache httpd regarding AAA (since for one it is not bound by the servlet spec), and once a request is authenticated, Apache and the connector will happily pass this authenticated id to Tomcat. And you would have to change nothing to your servlet-engine side code, singletons and all. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Basic and Form Authentication
Hi, Is is possible to have an application that serves content protected by BASIC and FORM based auth? i.e. JSP protected by FORM Servlets that process XML use http BASIC? I could deploy seperate apps for each type but I would then lose access to application specific information e.g. Singletons and Statics, which will cause big problems. Any words of wisdom? Tony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Some advice on apache tomcat
Hi, I have failed to come up with a solution to link Apache 2.2 and Tomcat 6 using mod_jk / mod_proxy_ajp in a way that satisfies my requirements. (Seamless form based authentication, CMS using wordpress etc.) I can get 98% there but the last 2% is the blocker and I am running out of options. I was very surprised that others have not done this before but then again I suppose every solution is different! (Many thanks to the replies for my earlier question, I don't think a non custom solution exists for it!) So to move forward I think that I will scrap putting the static content on apache and serve it all from tomcat. I might use apache to handle SSL and loadbalance. My question is what is the recommended wordpress replacement that I can use on Tomcat to provide content management via database as well as providing blogging capability? I looked at quercus php enabler for tomcat but it seems to have a commerical license. openCMS looks promising (but no blogging) any recommendations? Tony On Tue, 17 Nov 2009 10:02 +, Pid p...@pidster.com wrote: On 16/11/2009 22:07, André Warnier wrote: Anthony Jay wrote: My main issue now is about how the authentication works between Tomcat and Apache. That's the only one I can readily answer. It is extremely simple with mod_jk. If the user is authenticated at the Apache level, mod_jk will pass this on to the Tomcat server via AJP. The only thing to do, is set the 'tomcatAuthentication=false' attribute in Tomcat's AJP Connector, and Tomcat will just believe the user-id sent by Apache and mod_jk. I don't know if, or how, mod_proxy_ajp handles the same thing. In terms of authentication, which should I use, mod_auth_mysql and mod_auth_dbm (or mod_auth_form in future or something else?) and why? There are many many possibilities for this under Apache httpd. Just pick the one that you like best, on its own merits. They all basically in the end result in the HTTP request being authenticated at the Apache httpd level (iow to have a user-id), and that's what you want. What you then do with it under Tomcat is another story, but that is also your choice. In terms of single sign on how can I make the user experience seamless between static content-managed pages and jsp/servlets? Will mod_jk handle sso? This does not seem clear to me in all the pages I read. If I configure form based auth in a login.jsp page will this be relayed to apache after a redirect? No, but why would it be ? Ah, if you want to do the authentication in Tomcat rather than in Apache, but still use it in Apache ? There are ways, but you'll need to write your own Apache (httpd) authentication module. You could then define a dummy servlet in Tomcat, which just echoes the authenticated user-id (as gotten via getRemoteUser() e.g.). Then in Apache httpd, you would make a side-request (oherwise known as a sub-request) to this Tomcat webapp to get the user-id, and use it to authenticate the current request in Apache. But that is a complicated scheme, probably only worth it if you find some Tomcat authentication method that does not exist in Apache httpd, which is unlikely. What is best practise and what should I be doing? If there is some hard to find documentation out there with pointers and tips I would appreciate a few links. To read in the Apache httpd docs : http://httpd.apache.org/docs/2.2/howto/auth.html Also, personally I would recommend having a look around here : http://cpan.uwinnipeg.ca/search?query=apache%3A%3Aauthmode=dist This is the Perl library. Even if you do not intend to do anything with Perl, the documentation of many of these modules is a goldmine of information about how things work. Expert advice is appreciated. You just got it. ;-) There used to be a mod_auth_cookie module that had form auth capabilities, but it wasn't ever in the main distro, it was listed in the related modules site. I used a variant of it in a HTTPD 1.3 install many years ago, so I can't vouch for its current status. GIYF. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Some advice on apache tomcat
Yep, I had come accross mod_auth_cookie, but its current status is questionable and people seem to have moved on to other things. I am just trying to find out what those other things are! Best practises etc. It would be nice to conduct a poll to find out what people are actually using. I am accepting that almost everyone else knows more than me Tony On Tue, 17 Nov 2009 10:02 +, Pid p...@pidster.com wrote: On 16/11/2009 22:07, André Warnier wrote: Anthony Jay wrote: My main issue now is about how the authentication works between Tomcat and Apache. That's the only one I can readily answer. It is extremely simple with mod_jk. If the user is authenticated at the Apache level, mod_jk will pass this on to the Tomcat server via AJP. The only thing to do, is set the 'tomcatAuthentication=false' attribute in Tomcat's AJP Connector, and Tomcat will just believe the user-id sent by Apache and mod_jk. I don't know if, or how, mod_proxy_ajp handles the same thing. In terms of authentication, which should I use, mod_auth_mysql and mod_auth_dbm (or mod_auth_form in future or something else?) and why? There are many many possibilities for this under Apache httpd. Just pick the one that you like best, on its own merits. They all basically in the end result in the HTTP request being authenticated at the Apache httpd level (iow to have a user-id), and that's what you want. What you then do with it under Tomcat is another story, but that is also your choice. In terms of single sign on how can I make the user experience seamless between static content-managed pages and jsp/servlets? Will mod_jk handle sso? This does not seem clear to me in all the pages I read. If I configure form based auth in a login.jsp page will this be relayed to apache after a redirect? No, but why would it be ? Ah, if you want to do the authentication in Tomcat rather than in Apache, but still use it in Apache ? There are ways, but you'll need to write your own Apache (httpd) authentication module. You could then define a dummy servlet in Tomcat, which just echoes the authenticated user-id (as gotten via getRemoteUser() e.g.). Then in Apache httpd, you would make a side-request (oherwise known as a sub-request) to this Tomcat webapp to get the user-id, and use it to authenticate the current request in Apache. But that is a complicated scheme, probably only worth it if you find some Tomcat authentication method that does not exist in Apache httpd, which is unlikely. What is best practise and what should I be doing? If there is some hard to find documentation out there with pointers and tips I would appreciate a few links. To read in the Apache httpd docs : http://httpd.apache.org/docs/2.2/howto/auth.html Also, personally I would recommend having a look around here : http://cpan.uwinnipeg.ca/search?query=apache%3A%3Aauthmode=dist This is the Perl library. Even if you do not intend to do anything with Perl, the documentation of many of these modules is a goldmine of information about how things work. Expert advice is appreciated. You just got it. ;-) There used to be a mod_auth_cookie module that had form auth capabilities, but it wasn't ever in the main distro, it was listed in the related modules site. I used a variant of it in a HTTPD 1.3 install many years ago, so I can't vouch for its current status. GIYF. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Some advice on apache tomcat
Hi, I am in need of some advice. My current setup is a web application running on Jboss which serves static and dynamic content, jsp, servlets and xml on two non load balanced servers (hot spare using mysql replication). It currently uses Http Basic Authentication over SSL. This has been fine to date but since I dont use any of EJB or related features I think that it is overkill for my application, as well as being unflexible w.r.t. deployment and content management as the whole site is deployed as a single EAR. Initially it was fantastic as it was simple and easy to maintain but now every change requires a full build. I am researching porting my site to Apache 2.2 and Tomcat, and hope to gain the following. 1. Serve the static content from apache e.g. images, clips sound, text files etc. 2. Install a CMS to offload content managment to others and also blog functionality, Wordpress seems to be the tool of choice for ease of usage and widespread usage, this seems to work fine in my test environment. 3. Maintain current servlet and jsp (including xml) functionality on tomcat. Instead of one super application I can deploy servlets as seperate applications and update them seperately. 4. Use connectors such as mod_jk to load balance and provide failover. I already have heartbeat and mod_jk installed on in high availabilty mode using workers in a test environment and this is working as expected. (Apache 2.2 and tomcat 6 running on centos 5.3). At this point I have hit a brick wall w.r.t. what to do next. I have been researching this for the past two weeks and the more I learn the more I seem to be confused. There is so much documentation on some things but almost none on others. I always fear that if there is nobody asking questions about a certain topic it either means that a) There are no problems using the technology or b) Nobody is using it at all. My main issue now is about how the authentication works between Tomcat and Apache. I would like to use both Form based and http basic authentication on protected resources running on both apache and tomcat. i.e. Form based for humans and httpbasic for XML requests over ssl. I have a user database in mysql containing username and password, roles are in another table but these could be merged if required. I also am confused by mod_jk and mod_proxy_ajp, they, seem to have much feature overlap. mod_proxy_ajp in my view suffers terribly from the missing *.jsp wildcard capability but has a much simpler configuration and better future prospects as it is bundled with apache 2.2. In terms of authentication, which should I use, mod_auth_mysql and mod_auth_dbm (or mod_auth_form in future or something else?) and why? In terms of single sign on how can I make the user experience seamless between static content-managed pages and jsp/servlets? Will mod_jk handle sso? This does not seem clear to me in all the pages I read. If I configure form based auth in a login.jsp page will this be relayed to apache after a redirect? What is best practise and what should I be doing? If there is some hard to find documentation out there with pointers and tips I would appreciate a few links. Expert advice is appreciated. Tony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Some advice on apache tomcat
Hi Neil, Thanks for the comments, I really appreciate hearing from someone that has actual production experience using these technologies! To answer your question below, I *could* have all my servlets in one webapp but that would not be my preference. For example I would like the capability be able to update a single servlet that serves XML without affecting any other user interations with the server, or, more realistically, to completely deploy a new application inluding jsp/servlets into Tomcat as a customer beta and keep current applications unaffected. (We have several new applications under development!) In addition Some servlets need http basic, some form based auth and others not even ssl at all! So from your mail I understand that you only use apache to serve static pages that are not protected, thereby needing no authentication and therefore you can contain all your Auth using Tomcat. This is good, how do you handle ssl? Does Apache terminate any SSL, all ssl or only static pages? Tony On Mon, 16 Nov 2009 12:24 -0600, Neil Aggarwal n...@jammconsulting.com wrote: Anthony: I am researching porting my site to Apache 2.2 and Tomcat, and hope to gain the following. 1. Serve the static content from apache e.g. images, clips sound, text files etc. I do that will all of my JSP apps. I set up Apache on the front end and use mod_jk to push JSP/servlet stuff into Tomcat. It works very well and scales nicely. 2. Install a CMS to offload content managment to others and also blog functionality, Wordpress seems to be the tool of choice for ease of usage and widespread usage, this seems to work fine in my test environment. That should be no problem. Wordpress is just a php app in front of MySQL. 3. Maintain current servlet and jsp (including xml) functionality on tomcat. Instead of one super application I can deploy servlets as seperate applications and update them seperately. Are you talking about having multiple service in one webapp or servlets in different webapps? 4. Use connectors such as mod_jk to load balance and provide failover. Like you said, this works very well. My main issue now is about how the authentication works between Tomcat and Apache. I would like to use both Form based and http basic authentication on protected resources running on both apache and tomcat. i.e. Form based for humans and httpbasic for XML requests over ssl. I have a user database in mysql containing username and password, roles are in another table but these could be merged if required. I put all protected info in Tomcat and only use Apache for sending public content. If there is a static file that needs protecting, I use a servlet that checks if they are logged in and then opens and streams the file back to the user. It works well. In terms of single sign on how can I make the user experience seamless between static content-managed pages and jsp/servlets? If you use one webapp with multiple servlets and serve your protected static content from Tomcat, SSO is very easy. I hope this helps, Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net Host your tomcat app on a CentOS VPS for only $25/month! Unmetered bandwidth, 7 day no risk trial, Google Checkout - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Java Out of Heap Issue
What I have found works well in some circumstances where you do not have a profiler to hand. 1. Look for static declarations in your code that point to singletons or collection objects. They might just grow and grow 2. You may not be using third party libs correctly, e.g. Not closing connections, performing cleanup etc. RTFM just in case. 3. Perform amputations on your code if possible i.e. replace methods with dummy invocations. You will *eventually* find the source of festering objects that are not being gc'd. Tony On Mon, 16 Nov 2009 15:54 -0800, Elli Albek e...@sustainlane.com wrote: You can try getting an object dump from a profiler and see which objects are the source of memory starvation. Simple JSPs are very unlikely to cause memory starvation, but you mentioned “application code”, which implies that you have more than simple JSPs. A few things you want to cross off your performance check list, which will not solve your problem, but are generally necessary: 1. JVM -server option, just in case 2. Disable session persistence 3. If you application does not use sessions, disable them for all JSPs (typical place to do it is header JSP include) 4. Force session termination, no long running sessions. 5. Remove all apps that you do not need. Tomcat comes with a few built in apps and those are not trivial to find. Make sure conf/Catalina and all its sub directories contain only apps that you need. Host manager and such should be deleted. Same with war files. What you describe in your memory graph is a simple memory leak. Generally, I would look in that order: 1. Sessions 2. Application code 3. Other webapps 1 and 3 are easy to deal with. If you don’t need sessions make sure they are not created at all. If you do, force session termination after a few minutes in master web.xml or other XML files. Notice that one file can define a value and another can overwrite it, so you have to make sure all are checked. If that does not work, application code is the next candidate. You can start with an object dump with a profiler or a simple code review/step through in a debugger. E - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Some advice on apache tomcat
Thanks. Squid may be a contender but I need the CMS and blogging that comes with apache/php. Although maybe someday our traffic may get to the point where we will need squid to keep up! Now that would be a good problem to have! Thanks for the pointer. On Mon, 16 Nov 2009 15:36 -0800, Elli Albek e...@sustainlane.com wrote: You can also look at squid to serve static files and load balance. So squid fronts tomcat and your other apps. Squid can serve your static files as well. All you have to do it make sure your static files return a cache header like max-age, and squid will serve them without going to the origin (tomcat). Squid can also load balance tomcats and route requests for multiple origins based on some rules. We have squid doing virtual hosting of tomcats that run different apps, as well as serving static content and caching dynamic content. The down sides vs apache: 1. Not as many plugins and options 2. The configuration rules are simpler and more widely known/understood in apache 3. Hard to rewrite URLs. Not impossible, but mod rewrite is much much easier to deal with. Actually any manipulation of the request/response is less than trivial on squid. If you go for squid, 2.7 and above. Earlier versions are not as good for reverse proxing. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Some advice on apache tomcat
Thank you very much for your informative comments. In terms of breaking an application into single servlets, I agree that there would need to be strong reasons for doing it, and the clear one that springs to mind is the requirement to have different authn methods for each, None, Form, and http basic. But I take your point on board. I really want to leverage as much flexibility between apache and tomcat but keep the dependencies and configuration to a minimum. I dream of a time where I can be lazy in the future. (Fat chance) Is there a lack of form-based authentication module (production ready) for apache or am I just really bad at finding things? I would really like to force apache to do as much as possible of the ssl and authn and leave tomcat to handle the actual work! Regards, Tony On Mon, 16 Nov 2009 21:07 +, Pid p...@pidster.com wrote: On 16/11/2009 17:53, Anthony Jay wrote: Hi, I am in need of some advice. My current setup is a web application running on Jboss which serves static and dynamic content, jsp, servlets and xml on two non load balanced servers (hot spare using mysql replication). It currently uses Http Basic Authentication over SSL. This has been fine to date but since I dont use any of EJB or related features I think that it is overkill for my application, as well as being unflexible w.r.t. deployment and content management as the whole site is deployed as a single EAR. Initially it was fantastic as it was simple and easy to maintain but now every change requires a full build. I am researching porting my site to Apache 2.2 and Tomcat, and hope to gain the following. 1. Serve the static content from apache e.g. images, clips sound, text files etc. 2. Install a CMS to offload content managment to others and also blog functionality, Wordpress seems to be the tool of choice for ease of usage and widespread usage, this seems to work fine in my test environment. 3. Maintain current servlet and jsp (including xml) functionality on tomcat. Instead of one super application I can deploy servlets as seperate applications and update them seperately. One servlet per application probably isn't an optimal solution. Breaking a single large app into smaller components may be worth it - very much depends on your application. 4. Use connectors such as mod_jk to load balance and provide failover. I already have heartbeat and mod_jk installed on in high availabilty mode using workers in a test environment and this is working as expected. (Apache 2.2 and tomcat 6 running on centos 5.3). At this point I have hit a brick wall w.r.t. what to do next. I have been researching this for the past two weeks and the more I learn the more I seem to be confused. What are you confused about? There is so much documentation on some things but almost none on others. I always fear that if there is nobody asking questions about a certain topic it either means that a) There are no problems using the technology or b) Nobody is using it at all. There are lots of questions about mod_jk on this list each week. Sometimes they're even different ones. ;) My main issue now is about how the authentication works between Tomcat and Apache. It's one way, Tomcat, as an 'inner' component, can defer to authentication set at the outer level in Apache HTTPD. See the tomcatAuthentication attribute of the AJP connector. http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html Tomcat can't pass it's authenticated principal up to HTTPD. I would like to use both Form based and http basic authentication on protected resources running on both apache and tomcat. You would probably need to seperate those parts into separate applications as FORM and BASIC can only be set once in each web.xml. (You can of course duplicate the same class or jar in differently configured web apps.) i.e. Form based for humans and httpbasic for XML requests over ssl. I have a user database in mysql containing username and password, roles are in another table but these could be merged if required. I also am confused by mod_jk and mod_proxy_ajp, they, seem to have much feature overlap. mod_proxy_ajp in my view suffers terribly from the missing *.jsp wildcard capability but has a much simpler configuration and better future prospects as it is bundled with apache 2.2. They offer similar, largely overlapping functionality, you choose one or the other. mod_proxy_ajp can of course handle *.jsp, when combined with mod_rewrite and the [P] proxy rewrite command. RewriteRule ^/(.+)\.jsp(.+)? ajp://tomcathost/$1.jsp$2 [P,L] In terms of authentication, which should I use, mod_auth_mysql and mod_auth_dbm (or mod_auth_form in future or something else?) and why? Up to you. In terms of single sign on how can I make the user experience seamless between static content
