Logging cookies in Tomcat 7

2012-11-26 Thread Russ Kepler
I'm running Tomcat 7 with juli logging enabled and so I'm seeing the standard 
logfiles.  In my access log I'm seeing the standard entries on each line and 
I'd like to see the cookies being passed as well - is there an easy way to do 
this - a property to set on the start up or something similar?

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Logging cookies in Tomcat 7

2012-11-26 Thread Russ Kepler
On Monday, November 26, 2012 01:44:25 PM Christopher Schultz wrote:

 On 11/26/12 1:27 PM, Russ Kepler wrote:
  I'm running Tomcat 7 with juli logging enabled and so I'm seeing
  the standard logfiles.  In my access log I'm seeing the standard
  entries on each line and I'd like to see the cookies being passed
  as well - is there an easy way to do this - a property to set on
  the start up or something similar?
 
 Do you need to be able to see arbitrary cookies, or do you have a
 specific list of cookies for which you'd like to see values?

I'm trying to see if I'm passing the right jsessionid from a Java Web Start 
application.  I've found the AccessLogValve entry in the server.xml and added 
%{jsessionid}c to the log pattern.  I'm not seeing anything added to the log 
output, adding some plaintext to the pattern showed that I was in the right 
neighborhood.  I tried %c and got ???c???, so if there  doesn't seem to be a 
general print the cookies pattern.  I see a %S and that seems to be printing 
the session id but the session id seems to be changing between accesses:

127.0.0.1 - webtyper [26/Nov/2012:11:56:29 -0700] GET /WebTyper/Hello.jsp 
HTTP/1.1 0B9EA01DEAD73DB885183DEC535251B7 200 470
127.0.0.1 - webtyper [26/Nov/2012:11:56:30 -0700] GET /WebTyper/appload.jsp 
HTTP/1.1 0B9EA01DEAD73DB885183DEC535251B7 200 814
127.0.0.1 - - [26/Nov/2012:11:56:31 -0700] GET /WebTyper/app/Webtyper.jar 
HTTP/1.1 61592CE719254921F8D1543FBE44A4FF 304 -
127.0.0.1 - - [26/Nov/2012:11:56:43 -0700] POST 
/WebTyper/data/json/typer/post HTTP/1.1 61592CE719254921F8D1543FBE44A4FF 403 
1195

(sorry for the split lines)

So between the Java Web Start accessing the .jnlp and .jar the session id 
changes, and I thought I was setting it properly on the client end.  The 
servlet is being dispatched through  HttpServletDispatcher but I thought the 
session id would be common.  Am I mistaken or just screwed up in my thoughts?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Logging cookies in Tomcat 7

2012-11-26 Thread Russ Kepler
On Monday, November 26, 2012 12:05:45 PM Russ Kepler wrote:
 On Monday, November 26, 2012 01:44:25 PM Christopher Schultz wrote:
  On 11/26/12 1:27 PM, Russ Kepler wrote:
   I'm running Tomcat 7 with juli logging enabled and so I'm seeing
   the standard logfiles.  In my access log I'm seeing the standard
   entries on each line and I'd like to see the cookies being passed
   as well - is there an easy way to do this - a property to set on
   the start up or something similar?
  
  Do you need to be able to see arbitrary cookies, or do you have a
  specific list of cookies for which you'd like to see values?
 
 I'm trying to see if I'm passing the right jsessionid from a Java Web Start
 application.  I've found the AccessLogValve entry in the server.xml and
 added %{jsessionid}c to the log pattern.  I'm not seeing anything added
 to the log output, adding some plaintext to the pattern showed that I was
 in the right neighborhood.  I tried %c and got ???c???, so if there 
 doesn't seem to be a general print the cookies pattern.  I see a %S and
 that seems to be printing the session id but the session id seems to be
 changing between accesses:

Bad form replying to myself, but the cookie name seems to be case sensitive.  
Changing the form to %{JSESSIONID}c seems to be printing the right cookie.  
Here's the log using %{JSESSIONID}c %S

127.0.0.1 - webtyper [26/Nov/2012:12:11:12 -0700] GET /WebTyper/Hello.jsp 
HTTP/1.1 0B9EA01DEAD73DB885183DEC535251B7 8953D71715F23F7528C0C70B384B3F44 
200 470
127.0.0.1 - webtyper [26/Nov/2012:12:11:13 -0700] GET /WebTyper/appload.jsp 
HTTP/1.1 8953D71715F23F7528C0C70B384B3F44 8953D71715F23F7528C0C70B384B3F44 
200 814
127.0.0.1 - - [26/Nov/2012:12:11:13 -0700] GET /WebTyper/app/Webtyper.jar 
HTTP/1.1 - 9319C7008BC21C4894AF24C985B3F727 304 -
127.0.0.1 - - [26/Nov/2012:12:11:27 -0700] POST 
/WebTyper/data/json/typer/post HTTP/1.1 9319C7008BC21C4894AF24C985B3F727 
9319C7008BC21C4894AF24C985B3F727 403 1195

I still am getting 403 on the last access with what seems to be the right 
session id.  

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Form based login authentication

2012-11-19 Thread Russ Kepler
On Monday, November 19, 2012 12:33:26 PM Brian Burch wrote:

 This issue was discussed at length on the users mailing list under this
 topic: AuthenticatorBase setChangeSessionIdOnAuthentication without
 cookies
 http://mail-archives.apache.org/mod_mbox/tomcat-users/201209.mbox/%3C505EDA8
 7.1080...@pingtoo.com%3E
 
 
 Authenticated access to restricted resources can only happen if the
 browser tells tomcat the session id when it requests ANY of those
 restricted resources. This is usually done via cookies, but when cookies
 are turned off the webapp has to keep reminding the browser of the
 session id - especially if the default behaviour is being used by the
 Container, when the session id is deliberately changed after authentication.
 
 Your protected jsp's MUST ALL use response.encodeURL() if you want your
 webapp to work properly without cookies.

OK, my confusion came from accessing the root and expecting the web.xml 
welcome-file tag to take care of my base page.  Is there a reason it doesn't 
get an encodeURL()?  When I make my initial page something that exists *and* 
encode the j_security_check things work, at least I get to my next stopping 
point with a .jnlp (I'd like javaws to load securely *then* access the 
servlets securely.  JWS documentation seems lacking and a couple of posts over 
here:

http://forums.oracle.com/forums/forum.jspa?forumID=944start=0

haven't elicited any enlightening responses.
 
 When using an IDE you need to be careful of classloader issues. Tomcat's
 classloader environment is sophisticated and I sometimes encounter
 strange behaviour under netbeans because it tries to cache classes for
 speed, but this sometimes means my changes do not seem to have worked.
 This can always be proved by restarting netbeans.

That's why I mentioned it.  When I get confused at a response I stop the web 
server from inside Eclipse, when that fails to unconfuse me I exit Eclipse and 
start back up.   So far I haven't seen much effect, i.e. my confusion remains, 
but at least I can break for coffee.

 I don't use eclipse, so I can't comment on your specific problems.
 However, you can simplify your debugging by running tomcat standalone
 and attaching your debugger to it.

I may get to that point, probably when I'm testing the .war

Thanks for looking at this.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Accidentally remove catalina.out file

2012-11-15 Thread Russ Kepler
On Thursday, November 15, 2012 02:35:10 PM Aliosh Neira wrote:
 What should happen when catalina.out is deleted? Please, I need to resolve
 this question.

So far as I know it's just a logfile and all that happens is that you lost the 
log output.  The file should be created on the next start of the server.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Accidentally remove catalina.out file

2012-11-15 Thread Russ Kepler
On Thursday, November 15, 2012 03:06:19 PM Aliosh Neira wrote:
 Even when the server is running and the file is deleted? Thank you.

If you restart the server you should get a 'new' catalina.out file.  Until you 
restart anything that should be logged is likely to be lost.

(I'm writing from assumptions on how logging works and how the Linux/Unix 
filesystems work.  If there's something specifically different about 
Apache/Tomcat/Catalina I wouldn't be aware of it).

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: This is just plain ... odd.

2012-11-08 Thread Russ Kepler
On Thursday, November 08, 2012 01:35:55 PM Lyallex wrote:

 I have tried everything I can think of to reproduce this behaviour
 in a standalone Java program but the list is always returned
 as required. When I call the method from a servlet the list is always
 returned
 in it's natural order, I know collections.sort is being executed as
 the list is in alpha order, it's almost as if the comparator is being
 replaced in some way
 
 I have no servlet filters or any other code 'in the way' between the facade
 and the initialization servlet.
 
 Any ideas ?

I'm not sure that you can ever get consistent results if the input order is 
random.  The Collections.sort() implements a merge sort and the merge sort 
depends on a consistent result from the compare() method.  As implemented the 
compare() will return what you want when the object being compared against is 
the Misc object but return a string compare when it isn't.  Try this:

   @Override
   public int compareTo(Category c) {
  if(category.equals(Miscellaneous)){
  return 1;
   } elseif (c.category.equals(Miscellaneous)) {
return -1;
   else{
  return category.compareTo(c.category);
   }
}

(side comment: If the list is a decent size it might make sense to compare 
against the Misc object rather than compare all strings but it's likely not 
worth the bother).

The was I usually handle this is to .remove the offending object from the list, 
sort, then .add it back on after the sort.  Keep the odd code local to the 
oddity.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Form based login authentication

2012-11-08 Thread Russ Kepler
Using:

Linux main 3.2.0-32
Tomcat 7.0.32
Java version 1.7.0_09
(working through Eclipse Juno)

I've been assigned what should have been a pretty simple task, a jnlp launcher 
following a login to the web server.  I've implemented what seemed to me to be 
the simplest solution - form based login going through j_security_check, after 
which I pass the jsessionid through a .jnlp built on the fly.  This would pass 
the session to the Java Web Start and let me pass it as well to me 
application.  I was planning on having the application perform the login 
manually if it isn't given a working session on startup.  I'm not having a lot 
of luck.

I believe that I have the user login bit setup correct as I see the failed 
login when I enter the incorrect login.  When I enter a working name/password 
pair I get a 408 - timeout.  That goes away if I change web.xml:

session-config
session-timeout30/session-timeout
tracking-modeURL/tracking-mode
/session-config

to the cookie form:

session-config
session-timeout30/session-timeout
tracking-modeCOOKIE/tracking-mode
/session-config

After that everything works as expected, so it appears that the 408 is related 
to the URL tracking.  I've tried this with the internal browser in Eclipse as 
well as Firefox and get the same problem.  I'm guessing the j_security_check 
isn't redirecting with a rewritten URL and instead returns a timeout on a 
successful login.

If this is a known behaviour I have not been able to find anything after 
spending a lot of time in google (more people seem to be trying to get rid of 
the url rewrite), but since this is a new environment I may not have a grip of 
the appropriate tags to be searching.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: This is just plain ... odd.

2012-11-08 Thread Russ Kepler
On Thursday, November 08, 2012 03:06:51 PM Lyallex wrote:
  I'm not sure that you can ever get consistent results if the input order
  is
  random.
 
 Well perhaps 'random' was a bit 'random' the select returns the data in the
 same order it was entered, ordered by id.
 Not necessarily the same as alpha as I'm sure you appreciate. the fact is
 that the data was always returned in the same order
 by the database, just not the order I wanted. This is why I was
 particularly confused.
 
 Whatever, your code works, now I just gotta figure out why

Because you were only handling one end of the compare against the special 
object.  Since the special object could appear as the object to be compared 
against as well as the object performing the compare the merge sort was being 
given conflicting comparisons against the special object - always the greatest 
when the special was performing the compare and alphabetically(ish) when it 
was the object given to the compare method.

You got the same (wrongish) results since you gave the sort the same order in 
the list.  I can't recall how merge sort can freak out when given conflicting 
compares, I seem to recall that you might get an endless loop under some 
circumstances as it orders and reorders the same group of objects.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: This is just plain ... odd.

2012-11-08 Thread Russ Kepler
On Thursday, November 08, 2012 10:05:43 AM djohn...@desknetinc.com wrote:
 
 This is closer, but still doesn't work correctly if two Misc categories
 are being compared, or one Misc category is compared to itself.
 Try:
 
 @Override
 public int compareTo(Category c) {
 if(category.equals(Miscellaneous)) {
 if(category.equals(c.category) return 0; // correctly
 handle equality.
 else return 1;
 } elseif (c.category.equals(Miscellaneous)) {
 return -1;
 } else {
 return category.compareTo(c.category);
 }
 }

You're right for the general case of compare(), but in my defense I'd like to 
say that merge sort will never compare the same object and the list was 
constrained to one special object, so in this case it'd work for the sort.

But it's likely better to handle the general case just in case someone other 
than the sort uses the compare() so your comment is well taken.  Nothing like 
fixing up one bad behaviour only to replace it with some more obscure one.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: This is just plain ... odd.

2012-11-08 Thread Russ Kepler
On Thursday, November 08, 2012 07:36:20 PM Lyallex wrote:

 The only difference between the two executions is the fact that the test
 code executes in
 it's own instance of the JVM whereas the other execution runs in an
 instance shared with the container.
 
 I accept that the behaviour may be undefined even though it is consistently
 repeatable in both environments
 but surely given everything else being equal the results should be the same
 ... or maybe I'm just losing the plot.

No, you're right but just missing some small difference in the environments.

I'd verify that you get the same input data in the same order in both cases, 
and that you're starting with the same size container and using the same sort, 
etc.  Something is different, if it isn't the data then it has to be in the 
code.  Last time I found something like this is was a replaced class caused by 
a classpath difference - maybe walk the debug and see exactly what is being 
executed in the sort?



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org