[Bug 55101] New: BasicAuthenticator parser and associated unit tests
https://issues.apache.org/bugzilla/show_bug.cgi?id=55101 Bug ID: 55101 Summary: BasicAuthenticator parser and associated unit tests Product: Tomcat 8 Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: br...@pingtoo.com Created attachment 30435 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30435&action=edit new inner class to parse credentials Now that tomcat uses a single Base64 decoder, I returned to the issues discussed in https://issues.apache.org/bugzilla/show_bug.cgi?id=54729. Mark's change to the primitive Basic parser in svn commit: r1459289 was my starting point, but I wanted to write a comprehensive set of unit tests that examined all the relevant edge cases under the new Base64 decoder. I felt the most sympathetic approach would be to mirror the way DigestAuthenticator uses an inner class which encapsulates the parsing logic and provides trivial accessor methods for the authentication tokens. A suitable signature for the inner class would allow me to instantiate and test it exhaustively without having to haul up a tomcat instance for each test case. I accept the previous advice that the best framework for testing authentication is by running tomcat and examining the output to the client, but this overhead is not necessary in every single edge case. As I developed the code, I quickly realised there would be no benefit in splitting the parser code (as DigestAuthenticator does), where some of it would have been moved to a new HttpParser.parseAuthorizationDigest method. The logic for parsing a Basic header seemed to be more clear when it was performed entirely by the new inner class. In particular, following Konstantin's comments, it would be unecessarily complex and slow to convert the ByteChunk to a StringReader for the required simple parsing process, and then returning the tokens as a HashMap. Having decided there was no point in slavishly following the parseAuthorizationDigest model, I have closed bz54729. At this stage, I only made two small changes to TestNonLoginAndBasicAuthenticator. Some of the tests will eventually be removed as redundant, but there is no harm keeping them initially to demonstrate backward compatibility. Two of the test cases in this suite now "fail" because they anticipate rejection from the old parser, while the new parser is more tolerant - exactly as described in the existing TODOs (which are now removed). My new test suite org.apache.catalina.authenticator.TestBasicAuthParser has three checkstyle errors that I am not sure how to resolve. I followed the "normal" junit style to have static imports for my two hamcrest assertions, but they are flagged with errors, e.g. "Using a static member import should be avoided - org.hamcrest.MatcherAssert.assertThat". Now that hamcrest core is no longer shipped within junit, do we need another checkstle rule? I hope you find these changes acceptable. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55101] BasicAuthenticator parser and associated unit tests
https://issues.apache.org/bugzilla/show_bug.cgi?id=55101 --- Comment #1 from Brian Burch --- Created attachment 30436 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30436&action=edit remove TODOs with more tolerant parser -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55101] BasicAuthenticator parser and associated unit tests
https://issues.apache.org/bugzilla/show_bug.cgi?id=55101 --- Comment #2 from Brian Burch --- Created attachment 30437 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30437&action=edit new test class for Basic authorization parser and Base64 decoder -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54729] new HttpParser.parseAuthorizationBasic method
https://issues.apache.org/bugzilla/show_bug.cgi?id=54729 Brian Burch changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Brian Burch --- This change is no longer appropriate. A better solution has been proposed. Please see https://issues.apache.org/bugzilla/show_bug.cgi?id=55101 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
MD5Encoder.encode versus HexUtils.toHexString
All,
While looking into a patch for BasicRealm, I noticed that there are two
classes that convert byte[] to a hex-encoded string (e.g. byte[] { 1, 2,
a, b ] -> "12ab"): HexUtils and MD5Encoder.
MD5Encoder only has a single method (encode) and it does exactly what
HexUtils.toHexString does, except that it only works for exactly 16-byte
arrays.
I haven't actually written any performance tests, but looking at the
code it seems that HexUtils.toHexString would execute slightly faster
for a 16-byte array because of repeated integer multiplication in the loop.
Is there a reason for MD5Encoder to exist? It appears only to be used in
the following classes:
RealmBase
DigestAuthenticator
WebdavServlet
Although I suppose a specialty 16-byte-only method might be written to
be slightly faster than the general-purpose HexUtils.toHexString method,
I'm not sure it's worth having a separate class/method to do it.
Any objections to using HexUtils.toHexString uniformly and removing the
MD5Encoder class entirely?
Thanks,
-chris
signature.asc
Description: OpenPGP digital signature
[Bug 55102] New: Add ability to report time taken to prepare response
https://issues.apache.org/bugzilla/show_bug.cgi?id=55102 Bug ID: 55102 Summary: Add ability to report time taken to prepare response Product: Tomcat 8 Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: jboy...@apache.org Created attachment 30438 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30438&action=edit Patch against trunk@r1493385 to record and output time to commit Tomcat's AccessLogValve is able to report the time taken to send an entire request using %D. This is the total processing time and may be affected by network conditions. It is sometimes useful to be able to record the time taken by the server to prepare the response and send the first content to the client. Attached is a patch that records the time the response is committed and then allows that to be reported in the access log using a '%F' pattern (which is the same as used by the mod-log-firstbyte module for HTTPD). -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55102] Add ability to report time taken to prepare response
https://issues.apache.org/bugzilla/show_bug.cgi?id=55102 --- Comment #1 from Jeremy Boynes --- Related post on users list: http://markmail.org/thread/vq3n2igy7q5fttc4 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Release Taglibs 1.2?
After a recent post on taglibs-user a couple of people have pinged me off-list expressing interest in an actual released version. I'd like to go ahead with that if no-one sees any issues. The code is ready, with no non-blocking issues and has previously passed the TCK. I will update my TCK setup and re-run with the latest version of Tomcat 7 (7.0.41) just to verify. The existing website content is dated and I'm not sure how to republish that with mvn/svnpubsub. I would appreciate some help/pointers on pulling that together. Thanks Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Release Taglibs 1.2?
2013/6/15 Jeremy Boynes : > After a recent post on taglibs-user a couple of people have pinged me > off-list expressing interest in an actual released version. I'd like to go > ahead with that if no-one sees any issues. > > The code is ready, with no non-blocking issues and has previously passed the > TCK. I will update my TCK setup and re-run with the latest version of Tomcat > 7 (7.0.41) just to verify. > > The existing website content is dated and I'm not sure how to republish that > with mvn/svnpubsub. I would appreciate some help/pointers on pulling that > together. > I know that Tomcat Maven Plugin has instructions on publishing its site in its README.txt file and there is also "deploySite.sh" script there. See [1]. I never used those steps, but I hope that gives a pointer. [1] http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/ Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
