• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

form authenticaiton using https

Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hello ,i am implementing form authentication using https.but i am not sure where to place tomcat-config.xml file & what is the role of server.xml file .i am using eclipse ide.can anyone help me out .i am posting my code as follows:


web.xml file:



need help
Saloon Keeper
Posts: 27819
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eclipse has little to do with it other than that the WTP Tomcat runner makes a mess of things. I use the sysdeo plug-in instead, as it uses Tomcat's actual configuration information instead of an incomplete and easily-outdated clone the way the WTP plugin does.

Tomcat's server.xml is the master configuration file for Tomcat. It contains the elements that wire Tomcat's components together into an actual webapp server as well as server-global definitions. You can also define webapp contexts in server.xml, but you should not. Webapp contexts should either be defined as a separate META-INF/context.xml file in the webapp WAR or as an xml file in TOMCAT_HOME/conf/Catalina/localhost.

Security can be defined either at the global level (server.xml) or at the per-application level (context). Usually I do it at the context level, unless there's a site-wide security policy in effect or I'm using a Single Signon configuration (which, by definition is global).

The actual authentication and authorization for container-managed (J2EE standard) security is managed by the security Realm. The Realm uses plug-in components to allow a wide variety of choices for security references, including text files such as tomcat-users.xml, databases, LDAP/Active Directory and more (including custom plug-ins).

The tomcat-users.xml file was originally created for the Tomcat MemoryRealm plugin. I believe that the actual location of this file was configurable, but the default location was the TOMCAT_HOME/conf directory where server.xml also resides. The MemoryRealm is not really designed for production work. For one thing, if you wanted to add a user or change a role, you had to not only edit the tomcat-users.xml file, you had to restart Tomcat, since this file was only read at startup. Plus, as far as I know, it thereafter resided in RAM, so lots and lots of users and roles would make it eat into memory otherwise usable for webapps.

Since about Tomcat 6, one or 2 other Realm plugins were added that can also read tomcat-users.xml but are more flexible about it. However, the best use for MemoryRealm and its relatives is for testing or very small simple sites with few users. Serious production sites will generally want to employ a database or directory server or something whose uses go beyond the local server.
Consider Paul's rocket mass heater.
    Bookmark Topic Watch Topic
  • New Topic