RE: [Seriously OT] Help in diagnosing server unresponsiveness
On 2/6/2013 9:26 AM, Jeffrey Janner wrote: IMO, developer performance trumps runtime performance most of the time. >So, if you can create a more maintainable system in less time by using >EJB (or whatever), then you go ahead and do it: servers are cheap, >while developer time is expensive. > >- -chris Chris, I'd like to differ with you on this last point. As someone who's been a developer, support person, and admin, I've got a pretty good perspective on this subject. While servers may be cheap, they will never be cheap enough to overcome poor programming practices. I've worked with systems so poorly designed that we couldn't purchase a system big enough to run the software adequately, once you got above a handful of users. Yes, it's gotten to the point where systems are much cheaper than they used to be, while developer salaries are only increasing (supposedly), so wasting time on some minor performance improvement may not be cost-effective. However, when you aggregate the time that hundreds of users spend waiting on a response from a poorly designed, unresponsive system, I think you'll find that it trumps the cost of having the developer spending a few extra minutes to "get it right the first time". Generalized solutions, I think, include a substantial amount of code that isn't required for a given application. The additional code affects performance but with the speed, availability and low cost of hardware, people seem to be opting for packaged solutions that don't require their programmers to understand the details of the implementation. That seems short-sighted to me. As an aside, I wonder if, at some point, the energy costs of inefficient code will come into play. Don't wasted CPU cycles == wasted energy? -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Cannot run Web Services on Tomcat 7 (7.0.34) due to JaxWS libraries
We cannot run ws because of the jaxws libraries. After several days trying different approaches we think the problem is we need to add the jaxws libraries and also add the listeners. We also discovered that the metro version might be affecting. We tried adding the jaxws libraries but no results. We tried creating on ws with axis2 with no luck also. We are now trying with tomee to automatically add the libraries, but we have not succeded. Any ideas or suggestions?
RE: JMS in a Tomcat Environment
On 1/30/2013 3:27 PM, Jeff Sturm wrote: -Original Message- From: Williams, Nick [mailto:nicholas.willi...@ul.com] Sent: Wednesday, January 30, 2013 2:06 PM I'm curious. I know that, being open source, the Tomcat project generally welcomes volunteers who want to contribute features or improvements. However, I'd like to know at what point a feature is unwelcome in Tomcat. I know that Tomcat is not and does not desire to be a full JavaEE application server. So, with that in mind, does the community desire that Tomcat NOT ever have JMS implemented in it? Or, has it just never been done because nobody did it, and if a volunteer came along willing to implement JMS in Tomcat, would the community be open to that? I'll toss out my opinion here (noting that I do not speak for Tomcat developers nor the ASF, nor even my employer I suppose)... We have an application here that uses JMS, for which we selected HornetQ for a variety of reasons (e.g. "it's fast"). The app also happens to be hosted on a Tomcat web application server. However Tomcat knows nothing of our JMS implementation (with the exception of a single Java property we set to name our JNDI provider) and HornetQ surely does not care whether or not it is running within Tomcat. Tomcat is useful to me a fast and flexible HTTP server that implements some basic specifications (giving it a degree of interoperability with other webapp containers). With that in mind, it feels to me as though things like JDBC data sources and JMS topics/queues are not within the scope of what Tomcat ought to provide, and I don't wish to see Tomcat become big and bloated in an attempt to be everything to everyone. Indeed it seems odd to ask the question on a Tomcat list, unless the goal is to just solicit opinions on JMS providers from other list members who may have experience with one or more such provider. Having been a Java developer since 1.0, and having adopted the language initially for the beauty of its simplicity, I've watched it transform into an alphabet soup that includes EJB, JSP, J2EE, etc. None of those specifications provide valuable capabilities I cannot built into my own application simply by choosing and integrating the right libraries. Even as an "enterprise" developer it does not feel like the J2EE specification was written for me, and I find myself wishing that bit of nonsense would just fade into obscurity, and I would be free to peel back the layers of the various Java technologies to pick and choose the smallest, simplest components as I see fit. Anyway, please excuse the rant, and feel free to return to your normal email list perusal... -Jeff Hear, hear. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: deploy application in new service in tomcat
On 07/02/2013 13:03, Anil Goyal -X (anigoyal - Aricent Technologies at Cisco) wrote: > Hi, > > I am creating a new service in tomcat (7.0.20) with service name > 'catalina_new' and appBase='webapps' by doing some changes in server.xml. > I am keeping the appBase same as that for default service 'catalina' Why? A side effect will be that all apps in webapps are deployed to both services. This is because you've told Tomcat to do that. What do you gain by having the same appBase? > I have several applications deployed under webapps. > I want only a single application with context '/feeder' to be accesible > through new service. > > Condition: I do not want to have a separate appBase for new service and > deployed only the required app under this new appBase. Why not? Why have you invented a spurious and unnecessary condition like this? > In short, do we have a context based filtering in tomcat so that tomcat > incorporate request only from a specific context path and ignore all others No. p > Thanks > Anil > -- [key:62590808] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to limit the number of renegotiations for a single TLS / SSL connection
On 08/02/2013 15:05, Mark Thomas wrote: > On 08/02/2013 14:34, Caldarale, Charles R wrote: >>> From: dku...@ccilindia.co.in [mailto:dku...@ccilindia.co.in] >>> Subject: How to limit the number of renegotiations for a single TLS >>> / SSL connection >> >>> We are using - Tomcat Version - 6.0.18 >> >>> Please suggest the recommended solution for tomcat >> >> Try using a version of Tomcat that's newer than 4.5 years old. Many >> security-related fixes have gone in since then, and it's >> irresponsible to expose your site to situations that have been >> addressed years previously. If you check the changelog, I think >> you'll find this TLS issue was addressed quite some time ago; it may >> require a JVM upgrade as well. > > No, this is a different issue. Not to disagree with Mark T... but the point about using old software is still a good one. Tomcat 6.0.18 vs Tomcat 6.0.36 OpenSSL 0.9.8k (25-Mar-2009) vs OpenSSL 0.9.8y (05-Feb-2013) Focusing on particular issues like this, rather than addressing the big picture and using a more recent build of Open SSL and/or Tomcat (that will carry many fixes) means the OP is probably Doing IT Wrong. p -- [key:62590808] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJAX Authentification
I built a solution, that is working for me. The Servlet is doing a
login, copies the the authentication-data to the session and responds
with JSON-Data.
The problem with this solution is, that I have to access a private
member by using reflections, because the StandardSession-Object is
hidden with a Facade-Pattern.
It's very dirty, but perhaps it can help anyone.
public void doPost(HttpServletRequest req, HttpServletResponse res)
throws ServletException, java.io.IOException {
String username = req.getParameter("j_username");
String password = req.getParameter("j_password");
boolean success = false;
String errortext = null;
if (username!=null && password!=null) {
try {
// authenticate the current request
req.login(username, password);
// attention! only the request is authenticated
now
try {
// on
org.apache.catalina.session.StandardSession we can set the
"UserPrincipal" from the current request
// this object is private member of an
instance of
'StandardSessionFacade'
StandardSession tomcatSession =
(StandardSession)
getPrivateField(req.getSession(), "session");
// set the authentication-data to the
session
tomcatSession.setPrincipal(
req.getUserPrincipal() );
tomcatSession.setAuthType(HttpServletRequest.BASIC_AUTH);
tomcatSession.setNote(Constants.SESS_USERNAME_NOTE, username);
tomcatSession.setNote(Constants.SESS_PASSWORD_NOTE, password);
// OK
Log(jafaLogger.LVL_INFO_LOW, "Login
OK");
success = true;
}
catch (Exception e) {
success = false;
errortext = "Error configuring session:
" + e.getMessage();
Log(jafaLogger.LVL_ERR_HIGH, errortext);
}
}
catch (ServletException loginError) {
success = false;
errortext = loginError.toString();
}
}
else {
success = false;
errortext = "Username or password missing";
}
res.setContentType("application/json");
JSONObject jsonElement = new JSONObject();
try{
jsonElement.put("success", success);
if (!success && errortext!=null)
{
jsonElement.put("errortext", errortext);
}
}
catch (JSONException jsonException){}
PrintWriter out = res.getWriter();
out.write(jsonElement.toString());
out.flush();
out.close();
}
2013/2/9 Jimmy Johnson :
> I had the same requirements and ended up using Spring security. Although
> spring security is no set up for ajax itself, you can make a filter that
> catches all ajax context after it goes through the security class filters.
> Take a look here :
>
> http://static.springsource.org/spring-security/site/
>
> If you think this is a solution for you let me know and I can provide more
> details.
>
> Jimmy
>
> On Feb 8, 2013, at 8:35 AM, Johannes Meyer wrote:
>
>> Hi Konstantin,
>>
>> thank you for answer.
>>
>>> HttpServletRequest.login(..) ?
>>> (in a Servlet 3.0 application)
>>
>> If I call this function, only the current request is authorized, but
>> not the whole session.
>>
>> Is there any solution to authorize the session?
>>
>> Thank you,
>> Johannes
>>
>> 2013/2/8 Konstantin Kolinko :
>>> 2013/2/8 Johannes Meyer :
Hello all,
I'm developing a web application with asynchronous techniques (ExtJS).
The most pages are secured with a "security-constraint", so the user
has to log in at first.
The users gets prompted
Re: AJAX Authentification
I had the same requirements and ended up using Spring security. Although spring security is no set up for ajax itself, you can make a filter that catches all ajax context after it goes through the security class filters. Take a look here : http://static.springsource.org/spring-security/site/ If you think this is a solution for you let me know and I can provide more details. Jimmy On Feb 8, 2013, at 8:35 AM, Johannes Meyer wrote: > Hi Konstantin, > > thank you for answer. > >> HttpServletRequest.login(..) ? >> (in a Servlet 3.0 application) > > If I call this function, only the current request is authorized, but > not the whole session. > > Is there any solution to authorize the session? > > Thank you, > Johannes > > 2013/2/8 Konstantin Kolinko : >> 2013/2/8 Johannes Meyer : >>> Hello all, >>> >>> I'm developing a web application with asynchronous techniques (ExtJS). >>> >>> The most pages are secured with a "security-constraint", so the user >>> has to log in at first. >>> >>> >>> The users gets prompted a login dialog and can type in his username >>> and password. The data will be sent asynchronous to the server and the >>> user should be logged in. >>> >>> How can I implement it at best? >>> >>> I tried to work with FORM-authentication but it is not very elegant. >>> >>> Is there any solution to make an AJAX-Authentication? >>> >>> Or can I build a servlet, that logs the user in, without show him any >>> dialogs? >>> >> >> HttpServletRequest.login(..) ? >> (in a Servlet 3.0 application) >> >> - >> 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: Sharing session attributes across multiple webapps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris, On 2/9/13 7:48 AM, chris derham wrote: > >> I simply need a temporary string that is set during the session >> in one app to still be able to be displayed when the user goes to >> another app. > > > >> Am I missing something obvious here? > > > Couldn't you try a cookie? +1 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEWUVQACgkQ9CaO5/Lv0PARPwCgqiCBamOvFBAozsnrsq7a/t67 TqcAoIPyVTvonQxxQtUEMwy9x1rIHV54 =MCU8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sharing session attributes across multiple webapps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jerry, On 2/9/13 12:04 AM, Jerry Malcolm wrote: > I need to set and read a session attribute across multiple webapps. > I have googled this and have read many answers. The general > consensus is that setting crossContext="true" and/or setting > singleSignOn="true" and/or adding emptySessionPath="true" all > should make it work. None of those will work. > I have done all of that, but it doesn't seem to make any > difference. I still can't, in one app, see the session attribute > that is set in another app. This is actually required by the servlet specification which mandates that each webapp have a separate HttpSession. So, single-sign-on just makes it so you don't have to re-authenticate with the same server to get into a different webap, but you still have distinct sessions. crossContext and emptySessionPath just confuse things, here. > Am I missing something obvious here? Posts all over the web have > said it works for them. (??) They must be confused. > First question... 'should' I be able to see a session attribute > across sessions if I have the above config variables set > correctly? Nope. > If this is never intended to ever work, what are alternatives? Any tech that will allow you to share (private?) data will work: RDBMS, memcached, flat file, Amazon S3, etc. > Somebody suggested getContext( "aaa" ).setAttribute(). But if > I set a context variable, the data value going to be common to all > sessions in that context and not per user, correct? Correct. > Others have recommended setting up a database table and/or disk > files to write the data, etc. It seems that is way overkill to > have to go that massive amount of work and performance overhead to > keep track of a temporary session variable simply because I > structured and modularized my program into a couple of different > webapps. That sounds about right. Unfortunately, you have the servlet spec working against you, here. > I'm running TC 7.0.23 Upgrade. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEWUUcACgkQ9CaO5/Lv0PA8ZwCgjlMTw+p9f3i3YVOKaSaaukof 3GUAnRVzWT0cwggMNKNY8OJ6urBJX5uv =sRoP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to limit the number of renegotiations for a single TLS / SSL connection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Deepak, On 2/9/13 4:05 AM, dku...@ccilindia.co.in wrote: > we have not specified any specific connector protocol in the > connector tag, is that mean we are using native APR connector, and > if it is so, then as renegotiation is not permitted in APR why VA > tool says renegotiation DoS vulnerability, and it would be of great > help if you explain how to implement HTTP NIO or BIO connector to > handle this renegotiation issue. The default connector depends upon your system configuration. I believe if you have APR/tcnative available, Tomcat will use that and you'll get an APR/HTTP connector. Otherwise, you'll get the BIO connector. You have to specifically request the NIO connector. > ciphers="Some cipher" allowUnsafeLegacyRenegotiation="false" > maxThreads="5" scheme="https" secure="false" clientAuth="false" > sslProtocol="TLS" keystoreFile="cert.key" keystorePass="password" > /> Using the APR connector for SSL will be much faster than either BIO or NIO. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEWUC8ACgkQ9CaO5/Lv0PB+FwCfQLqO5CsHc9cB4sq+mO5D8mq5 IDMAoLr6WXRqgu7JWiHewUD47Js36dXd =XY13 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJAX Authentification
Johannes Meyer wrote: Hello all, I'm developing a web application with asynchronous techniques (ExtJS). The most pages are secured with a "security-constraint", so the user has to log in at first. The users gets prompted a login dialog and can type in his username and password. The data will be sent asynchronous to the server and the user should be logged in. How can I implement it at best? I tried to work with FORM-authentication but it is not very elegant. Is there any solution to make an AJAX-Authentication? Or can I build a servlet, that logs the user in, without show him any dialogs? Hi. Almost any HTTP authentication requirement can be solved, but whether it is easy, difficult, or impossible depends a lot on the details of the situation. So you will need to provide some additional data if you want more help. E.g. Is this an Internet server with clients being anywhere, or is it a purely Intranet situation ? If Intranet, are you using any form of Windows domain authentication ? What are the browsers ? (it can matter, if the Ajax in the browser uses its own connection and authentication, or shares it with the browser in general) What degree of security does this require ? Do the Ajax calls address the same host & webapp as the ones which the browser accesses ? Are you using some specific Ajax library to make those calls ? (if yes, which authentication methods does it support ?) Do you have an Apache httpd in front of Tomcat, or can you set one up ? (there are more authentication variations available for httpd than for tomcat, and the httpd-level authentication can be forwarded to tomcat) etc.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Need to Specify keystorePass on Command Line
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 2/8/13 5:03 PM, Harris, Jeffrey E. wrote: > For our implementation, it does not matter whether another process > can read the startup parameters - as long as the password is not > stored in a file and disappears when the Tomcat's host server is > shutdown. What about virtual memory? The OS can page anything any time it wants? Are you using whole-disk encryption? If you don't you are surely wasting your time. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEWTwEACgkQ9CaO5/Lv0PDYXgCfd/vOLTfTWdMw9aIpACJPZe4U nlQAnR8BKHvTYtXWcjqx3F3ZYHAjXLOr =K3YE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sharing session attributes across multiple webapps
> I simply need a temporary string that is set during the session in > one app to still be able to be displayed when the user goes to another > app. > Am I missing something obvious here? Couldn't you try a cookie? Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to limit the number of renegotiations for a single TLS / SSL connection
Hello All, @ Mark we have not specified any specific connector protocol in the connector tag, is that mean we are using native APR connector, and if it is so, then as renegotiation is not permitted in APR why VA tool says renegotiation DoS vulnerability, and it would be of great help if you explain how to implement HTTP NIO or BIO connector to handle this renegotiation issue. @Daniel Please find the connector tag of sever.xml Any help wold be appreciated. Thanks and regards Deepak. From: Mark Thomas To: Tomcat Users List Date: 02/08/2013 08:44 PM Subject:Re: How to limit the number of renegotiations for a single TLS / SSL connection On 08/02/2013 14:28, dku...@ccilindia.co.in wrote: > Hello All, > > We are using - > Tomcat Version - 6.0.18 > Operating System Version : HP-UX 11.31 > SSL Version - OpenSSL 0.9.8k 25 Mar 2009 > Port - 8443 > > By running the venerability assessment test we are getting the following > observation > > The remote service encrypts traffic using TLS / SSL and permits clients to > renegotiate connections. The computational requirements for renegotiating > a connection are asymmetrical between the client and the server, with the > server performing several times more work. Since the remote host does not > appear to limit the number of renegotiations for a single TLS / SSL > connection, this permits a client to open several simultaneous connections > and repeatedly renegotiate them, possibly leading to a denial of service > condition. > > Please suggest the recommended solution for tomcat To repeat what I have said privately on this topic: The Apache Tomcat security team has reviewed the available information for CVE-2011-1473 and has performed some testing of Apache Tomcat using one of the many tools that has be written to demonstrate this issue. Our conclusions are: - In terms of CPU usage there is not a large difference (same order of magnitude) between a client creating multiple HTTPS connections and a client creating a single HTTPS connection and repeatedly requesting renegotiation. This is consistent with the findings / opinions of the numerous SSL/TLS experts that have commented on this issue. - Repeated renegotiation attempts from a single client can be detected by a firewall. - Multiple connection attempts from a client are easier for a firewall to identify than multiple renegotiation requests. - Client renegotiation is not permitted by the HTTP APR/native connector. - It would be possible to add renegotiation rate limiting to the HTTP BIO and NIO connectors but there is not a clear-cut case for doing this. We would also draw your attention to the following text on the Apache Tomcat website security pages [1]: Note that all networked servers are subject to denial of service attacks, and we cannot promise magic workarounds to generic problems (such as a client streaming lots of data to your server, or re-requesting the same URL repeatedly). In general our philosophy is to avoid any attacks which can cause the server to consume resources in a non-linear relationship to the size of inputs. Further discussion of this issue, particularly the usefulness of adding renegotiation rate-limiting to the the HTTP BIO and NIO connectors, should take place on the public Tomcat users mailing list. Mark on behalf of the Apache Tomcat security team With all the above in mind is there an argument for introducing renegotiation rate limiting for BIO and NIO? Or do we just say if you are bothered about CVE-2011-1473, use APR. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org "Disclaimer and confidentiality clause - This message and any attachments relating to official business of CCIL OR ANY OF IT'S SUBSIDIARIES is proprietary to CCIL and intended for the original addressee only. The message may contain information that is confidential and subject to legal privilege. Any views expressed in this message are those of the individual sender. If you have received this message in error, please notify the original sender immediately and destroy the message and copies thereof and any attachments contained in it . If you are not the intended recipient of this message, you are hereby notified that you must not disseminate, copy, use, distribute, or take any action in connection therewith. CCIL cannot ensure that the integrity of this communication has been maintained nor that it is free of errors, viruses, interception and/or interference. CCIL is not liable whatsoever for loss or damage resulting from the opening of this message and/or attachments and/or the use of the information contained in this message and/or attachments."
