[OT] Re: Tomcat Valve

[logo]

Nice one Christopher. Didn't know that yet. Will bookmark.

Am 28.08.2018 05:13, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lance,

On 8/27/18 19:21, Christopher Schultz wrote:

Lance,

On 8/24/18 11:52, Campbell, Lance wrote:

Tomcat 9 Use Case 1:  I want to store the last N number of URLs
sent to Tomcat 9 application.  Then if Tomcat shuts down I want
to write out these last N number of URLs to the log file.



Strategy: I figured I would use a valve to keep track of the last
N number of URLs.  However I don’t know how to tell when the
valve is shutting down.



Does anyone have any suggestions?


Sounds like an X-Y problem: http://xyproblem.info/

Maybe you can tell us what Y is in this case?


Uhh... actually I meant "what is X, here?" ;)

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluEveUACgkQHPApP6U8
pFh5Og//djlqDz0WsiVlHg+Z6w6cGUiXAOd8FiQOMPPvgps9fl0rLU5bMteyRO4D
YKrU8zECfbvZxDnt1aVtxcqrKVaVvu/YyObIUG/6xQAN7pqEz3iJJ/7tWLhaGvHn
/fw+8oFHiO2rrodr9M8OFpeYklhqLkP1N0yxZVn9pfUQKcN0hWgOEwdHL2TWicZm
kx2MRs2hr2SRTs0dxmIYNVpy6ajRL8CDYY02rItCWGZZ3BLLNaePvRfkBn+BMfdm
W8XF1vArV8JvMkydvNk6Nq1U0uxRCf8eeDuT7DtJ8ls6j8FFIA34OuLmiXao+5Bl
E6YfKcpjJgxxlJqbuz3UTPiSSJ7HK/XkR1lZhz/GSJP5BhoCGFv8wiEwscH2b6pF
sbsT8gn1OqfVgHZPYMViqxXHxpLitbV1ZrtbmtY0QGyyGW8lUOWWTO/Jor1CTgKo
Jh+G1FOT4L5q0bE1WmloRxjwj+lg7beMwGjLKp9+Lu+yZRjvz+bJUJNacHr5ysG2
EQiCTKGHdaImtSs0vg0N8t13RmjgMhZljMxeX46bk4nZ+MsAX1SxnBN8kZdXVHKy
aVXIez73a3FhjLy0+fVZlObsHWPvHtvSpX3VN3Slnc0g5Lm6X2feeZLpnv6irs3y
Wos/zAFA5opTa4pBoqz6+q9A5Btx3EHJQAK9XqagqZbYWjJ/TLU=
=CJN/
-END PGP SIGNATURE-

-
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: Tomcat Valve

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lance,

On 8/27/18 19:21, Christopher Schultz wrote:
> Lance,
> 
> On 8/24/18 11:52, Campbell, Lance wrote:
>> Tomcat 9 Use Case 1:  I want to store the last N number of URLs 
>> sent to Tomcat 9 application.  Then if Tomcat shuts down I want
>> to write out these last N number of URLs to the log file.
> 
>> Strategy: I figured I would use a valve to keep track of the last
>> N number of URLs.  However I don’t know how to tell when the
>> valve is shutting down.
> 
>> Does anyone have any suggestions?
> 
> Sounds like an X-Y problem: http://xyproblem.info/
> 
> Maybe you can tell us what Y is in this case?

Uhh... actually I meant "what is X, here?" ;)

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluEveUACgkQHPApP6U8
pFh5Og//djlqDz0WsiVlHg+Z6w6cGUiXAOd8FiQOMPPvgps9fl0rLU5bMteyRO4D
YKrU8zECfbvZxDnt1aVtxcqrKVaVvu/YyObIUG/6xQAN7pqEz3iJJ/7tWLhaGvHn
/fw+8oFHiO2rrodr9M8OFpeYklhqLkP1N0yxZVn9pfUQKcN0hWgOEwdHL2TWicZm
kx2MRs2hr2SRTs0dxmIYNVpy6ajRL8CDYY02rItCWGZZ3BLLNaePvRfkBn+BMfdm
W8XF1vArV8JvMkydvNk6Nq1U0uxRCf8eeDuT7DtJ8ls6j8FFIA34OuLmiXao+5Bl
E6YfKcpjJgxxlJqbuz3UTPiSSJ7HK/XkR1lZhz/GSJP5BhoCGFv8wiEwscH2b6pF
sbsT8gn1OqfVgHZPYMViqxXHxpLitbV1ZrtbmtY0QGyyGW8lUOWWTO/Jor1CTgKo
Jh+G1FOT4L5q0bE1WmloRxjwj+lg7beMwGjLKp9+Lu+yZRjvz+bJUJNacHr5ysG2
EQiCTKGHdaImtSs0vg0N8t13RmjgMhZljMxeX46bk4nZ+MsAX1SxnBN8kZdXVHKy
aVXIez73a3FhjLy0+fVZlObsHWPvHtvSpX3VN3Slnc0g5Lm6X2feeZLpnv6irs3y
Wos/zAFA5opTa4pBoqz6+q9A5Btx3EHJQAK9XqagqZbYWjJ/TLU=
=CJN/
-END PGP SIGNATURE-

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

Re: Tomcat Valve

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lance,

On 8/24/18 11:52, Campbell, Lance wrote:
> Tomcat 9 Use Case 1:  I want to store the last N number of URLs
> sent to Tomcat 9 application.  Then if Tomcat shuts down I want to
> write out these last N number of URLs to the log file.
> 
> Strategy: I figured I would use a valve to keep track of the last N
> number of URLs.  However I don’t know how to tell when the valve is
> shutting down.
> 
> Does anyone have any suggestions?

Sounds like an X-Y problem: http://xyproblem.info/

Maybe you can tell us what Y is in this case?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluEh18ACgkQHPApP6U8
pFhPARAAhNHyEiiZeyoGN9MJKqPLtg+xneyuylr2ogIppparE20u5QPfXHs8LIoY
KdHcEldIsfgALeMoSf1yQ+mmmzRrwfXTWYk8sl+6bSzWmiPDh7Kzfkk+NbKCmuIw
P0lYk/1OPhDYWXVrv0OtztjxLyy+q1IyzRUF6L9A/j6wWmpdDbmgvARUYr88vaij
xsuPNFsEv59760g5Ax3STN8Pz9SJNAAScJGUURY4Y1gx62fzhLTjjuQJk59458hW
ju2SeceMKZDOYTLQtANArGaoayaNxsQC0zp1exSsjRcahhZFP9f84h3O6W03VCFd
aySRZEKw7RtH1W1TZVMJ+PdiwEEo2A8+g9eJOZqWx8J6Py0v0GUPyXczZCh8Uc24
OMdqJ778dhp6UjDeeEMIhDzmaws6BMrbqX/ghkCA2Wu9c6KXOuq3rW2tMi7r7nTa
3JEuYMNUXRTpSyCJl6ldFzhXK2Ly5a1hY1kGKR+5MPekDFNw+Y9uulgd2yK5beSv
9WOjwDSd3UTk3dIY5LiNumQlDIZ76jBnZDBwpuuvaZ/egKQZ5hgysdYGBroxBFXL
mGl1eOu9exks6TuCqpe5UXyPsaWFq40qwe5mvi/ra8qFc4z43mkLyGzwOcbsTT71
jyB8Ezau3aUkrsuLlPq4MZtjYZ/OWoq39ceH5kgguDra+u99Lpg=
=+9NE
-END PGP SIGNATURE-

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

RE: Tomcat Valve

[Jäkel , Guido]

Dear Lance

I don't know the motivation for your usecase. But note that the access log is 
written after handling the complete request (therefore its able to log the 
number of bytes send) and, because it's typical buffered, with a delay, too.

This means, that a request is listed there only in the case of a proper 
shutdown. If the Tomcat come down because of a JVM OOM or something like this, 
this might be inaccurate.

In addition, if you tell the Tomcat to shut down, one of the first steps is to 
block the "Connectors", i.e. the receivers for HTTP (and/or AJP). Request will 
be rejected then, but not logged anymore.  Then, further shutdown will happen, 
e.g. the shutdown of the Servlet Containere(s). This may take some notable time 
and during this, the JVM -- Maybe from another point of view called "the Tomcat 
Process" -- is still running.

Greetings

Guido

>-Original Message-
>From: Mark Thomas [mailto:ma...@apache.org]
>Sent: Friday, August 24, 2018 6:44 PM
>To: users@tomcat.apache.org
>Subject: Re: Tomcat Valve
>
>On 24/08/18 17:36, Campbell, Lance wrote:
>> I don't understand.  How does that help a valve running know that it is 
>> shutting down?  At that point it would be too late.
>
>The point is you don't need a valve to answer your question. Just look
>at the last 9 entries in the access log.
>
>Mark
>
>>
>> On 8/24/18, 11:06 AM, "Mark Thomas"  wrote:
>>
>> On 24/08/18 16:52, Campbell, Lance wrote:
>> > Tomcat 9
>> > Use Case 1:  I want to store the last N number of URLs sent to Tomcat 
>> 9 application.  Then if Tomcat shuts down I want
>to write out these last N number of URLs to the log file.
>> >
>> > Strategy:
>> > I figured I would use a valve to keep track of the last N number of 
>> URLs.  However I don’t know how to tell when the
>valve is shutting down.
>> >
>> > Does anyone have any suggestions?
>>
>> tail -n 9 ${CATALINA_BASE}/logs/localhost_access_log.-mm-dd.txt
>>
>> Mark
>>
>> -
>> 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: Tomcat Valve

[Mark Thomas]

On 24/08/18 17:36, Campbell, Lance wrote:
> I don't understand.  How does that help a valve running know that it is 
> shutting down?  At that point it would be too late.

The point is you don't need a valve to answer your question. Just look
at the last 9 entries in the access log.

Mark

> 
> On 8/24/18, 11:06 AM, "Mark Thomas"  wrote:
> 
> On 24/08/18 16:52, Campbell, Lance wrote:
> > Tomcat 9
> > Use Case 1:  I want to store the last N number of URLs sent to Tomcat 9 
> application.  Then if Tomcat shuts down I want to write out these last N 
> number of URLs to the log file.
> > 
> > Strategy:
> > I figured I would use a valve to keep track of the last N number of 
> URLs.  However I don’t know how to tell when the valve is shutting down.
> > 
> > Does anyone have any suggestions?
> 
> tail -n 9 ${CATALINA_BASE}/logs/localhost_access_log.-mm-dd.txt
> 
> Mark
> 
> -
> 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: Tomcat Valve

[Campbell, Lance]

I don't understand.  How does that help a valve running know that it is 
shutting down?  At that point it would be too late.  

On 8/24/18, 11:06 AM, "Mark Thomas"  wrote:

On 24/08/18 16:52, Campbell, Lance wrote:
> Tomcat 9
> Use Case 1:  I want to store the last N number of URLs sent to Tomcat 9 
application.  Then if Tomcat shuts down I want to write out these last N number 
of URLs to the log file.
> 
> Strategy:
> I figured I would use a valve to keep track of the last N number of URLs. 
 However I don’t know how to tell when the valve is shutting down.
> 
> Does anyone have any suggestions?

tail -n 9 ${CATALINA_BASE}/logs/localhost_access_log.-mm-dd.txt

Mark

-
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: Tomcat Valve

[Mark Thomas]

On 24/08/18 16:52, Campbell, Lance wrote:
> Tomcat 9
> Use Case 1:  I want to store the last N number of URLs sent to Tomcat 9 
> application.  Then if Tomcat shuts down I want to write out these last N 
> number of URLs to the log file.
> 
> Strategy:
> I figured I would use a valve to keep track of the last N number of URLs.  
> However I don’t know how to tell when the valve is shutting down.
> 
> Does anyone have any suggestions?

tail -n 9 ${CATALINA_BASE}/logs/localhost_access_log.-mm-dd.txt

Mark

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

Re: Tomcat Valve doing Request.getParameter() consumes the stream

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter,

On 5/28/15 3:44 PM, Teunissen,Peter wrote:
> (Tomcat 7)
> 
> I am writing a Valve that does a getParameter on the Request. At
> the end of the Valve/Filter chain is a servlet that calls
> HttpServletRequest.getReader() returning an empty buffer (because
> the Valve consumed it).
> 
> I tried hacking a wrapper for the Request together and pass that
> into the getNext().invoke , but not much luck yet (seems to be some
> state in the underlying coyoteStream/Request/Inputbuffer)
> 
> I can't imagine I'm the first to encounter this and yet I can't
> find a good wrapper example on the internet.
> 
> Anybody better suggestions?

You might be able to adapt this Filter I wrote to do the same thing:

http://markmail.org/thread/fumpfuspt7a3nesz

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVaLkcAAoJEBzwKT+lPKRYZegP/RJ3bJe2aZh2LGkXYjSCb1wn
KUdkscj0PrpT4uRMNDsoLkBMhzzJc33EjUNvlz60eNjUh0hL/PZ2aIV0suxJ+g83
KeziNOah6goaiJ77PgyyV9MFx76T24EvTgQPRAgKUrN84cbk8uGQ/iY2rBrM4A+7
CDUUEOHTb5oLq/s/oEEEDdC06XXCY/O03p+5WMPb5StEvYr2f8Iipa6AX7sYxlDT
D7i5z4kJnR4iYWmz7tU0FP7c0R0n5Mxz/alpoiydv2Gnfxb9wNY6wdge4td5fwIO
/QXqDGb/nDA7dpvzTYMQq8Fozi6sjxV7z6Au7P19TFQxbKBjYq5LEyh7B4FD88nO
QKuW8uyTcz0A028XWuy2Vu61LE5uGuHllXOrQjycZsTeH3FIyxJ5gRsKtlhxSrNw
2MVS2FxAG7J3mvM+RDMsethJsfAmF3p3CM3UeOB70vOghBnkPl5fHThJ2uwle6YT
yoy8n91Ls+ErWo+JFhHM5KTrX29MrT7l8berUSIhsMS5p1rw8Qu3WlIF4UT406yo
4LVPYSBfnem5aJa1Zfcc/fWVoWzNOeOUgpgsV2B2bPPSm2yBBtyAli2q+BGRBwSb
vtddKILo+RkujAId5OIFAfluw+nuiBqAGTBQRKc4pKFB7yIOmmuUH/a3E689jaCj
vtFSyy0acGimDfmQyXAE
=QES6
-END PGP SIGNATURE-

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

Re: Tomcat Valve doing Request.getParameter() consumes the stream

[Violeta Georgieva]

Hi,

2015-05-28 22:44 GMT+03:00 Teunissen,Peter :
>
> (Tomcat 7)
>
> I am writing a Valve that does a getParameter on the Request. At the end
of the Valve/Filter chain is a servlet that calls
HttpServletRequest.getReader() returning an empty buffer (because the Valve
consumed it).
>
> I tried hacking a wrapper for the Request together and pass that into the
getNext().invoke , but not much luck yet (seems to be some state in the
underlying coyoteStream/Request/Inputbuffer)
>
> I can't imagine I'm the first to encounter this and yet I can't find a
good wrapper example on the internet.
>
> Anybody better suggestions?

You may want to check this enhancement [1].

Regards,
Violeta

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=45014
>
>
> CONFIDENTIALITY NOTICE This message and any included attachments are from
Cerner Corporation and are intended only for the addressee. The information
contained in this message is confidential and may constitute inside or
non-public information under international, federal, or state securities
laws. Unauthorized forwarding, printing, copying, distribution, or use of
such information is strictly prohibited and may be unlawful. If you are not
the addressee, please promptly delete this message and notify the sender of
the delivery error by e-mail or you may call Cerner's corporate offices in
Kansas City, Missouri, U.S.A at (+1) (816)221-1024.

RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Kim Ming Yap]

ok. i see the light ..
Thanks a zillion! 😊

> Date: Tue, 19 May 2015 15:56:47 +0100
> From: ma...@apache.org
> To: users@tomcat.apache.org
> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> response reaches back to Tomcat valve
> 
> On 19/05/2015 15:51, David kerber wrote:
> > On 5/19/2015 10:46 AM, Kim Ming Yap wrote:
> >>
> >> You said ..
> >>
> >> "> Actually, the better analogy is that there is an application that can
> >>> tell you whether or not 1+1=2, and you're asking it to explain why the
> >>> numbers they entered don't total up to 2"
> >>
> >> when a user account is disabled after exceeded limits retry .. i
> >> couldn't display "account disabled" but rather "email / password
> >> invalid (due to the issue below)
> >>
> >> the right analogy is ..
> >>
> >> 1 (User) +1 (password) = 10 (10 being the incorrect message being
> >> displayed due to lack of the needed feature).
> >>
> >> Sure .. if if i'm the client .. i will ask 1+1 = 10?
> >>
> >> That's the issue.
> > 
> > The point we're making is that if a user's authentication is not valid,
> > you should NOT be telling them why, just tell them it's invalid and
> > maybe tell them to contact the administrator.
> > 
> > Giving them any more information is just setting yourself up to be a
> > victim of much quicker brute-force attacks, because you're giving them
> > lots of help.
> 
> +1.
> 
> And the chances of any such features making it into Tomcat are slim to
> none. I for one would veto any such proposal (for the exact reasons
> David outlines above).
> 
> It is possible that, if the GSoC project to implement JASPIC succeeds
> (and that isn't looking very likely right now), a side-effect may be
> that JASPIC makes it easier to implement custom authenticators but even
> then if you want to go down the route of detailed explanations for
> authentication failures you will be on your own.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
  

Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Mark Thomas]

On 19/05/2015 15:51, David kerber wrote:
> On 5/19/2015 10:46 AM, Kim Ming Yap wrote:
>>
>> You said ..
>>
>> "> Actually, the better analogy is that there is an application that can
>>> tell you whether or not 1+1=2, and you're asking it to explain why the
>>> numbers they entered don't total up to 2"
>>
>> when a user account is disabled after exceeded limits retry .. i
>> couldn't display "account disabled" but rather "email / password
>> invalid (due to the issue below)
>>
>> the right analogy is ..
>>
>> 1 (User) +1 (password) = 10 (10 being the incorrect message being
>> displayed due to lack of the needed feature).
>>
>> Sure .. if if i'm the client .. i will ask 1+1 = 10?
>>
>> That's the issue.
> 
> The point we're making is that if a user's authentication is not valid,
> you should NOT be telling them why, just tell them it's invalid and
> maybe tell them to contact the administrator.
> 
> Giving them any more information is just setting yourself up to be a
> victim of much quicker brute-force attacks, because you're giving them
> lots of help.

+1.

And the chances of any such features making it into Tomcat are slim to
none. I for one would veto any such proposal (for the exact reasons
David outlines above).

It is possible that, if the GSoC project to implement JASPIC succeeds
(and that isn't looking very likely right now), a side-effect may be
that JASPIC makes it easier to implement custom authenticators but even
then if you want to go down the route of detailed explanations for
authentication failures you will be on your own.

Mark

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

Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[David kerber]

On 5/19/2015 10:46 AM, Kim Ming Yap wrote:


You said ..

"> Actually, the better analogy is that there is an application that can

tell you whether or not 1+1=2, and you're asking it to explain why the
numbers they entered don't total up to 2"


when a user account is disabled after exceeded limits retry .. i couldn't display 
"account disabled" but rather "email / password invalid (due to the issue below)

the right analogy is ..

1 (User) +1 (password) = 10 (10 being the incorrect message being displayed due 
to lack of the needed feature).

Sure .. if if i'm the client .. i will ask 1+1 = 10?

That's the issue.


The point we're making is that if a user's authentication is not valid, 
you should NOT be telling them why, just tell them it's invalid and 
maybe tell them to contact the administrator.


Giving them any more information is just setting yourself up to be a 
victim of much quicker brute-force attacks, because you're giving them 
lots of help.







Date: Tue, 19 May 2015 10:34:48 -0400
From: dcker...@verizon.net
To: users@tomcat.apache.org
Subject: Re: Tomcat valve JAAS : form error page displayed first before 
response reaches back to Tomcat valve

On 5/19/2015 10:26 AM, Kim Ming Yap wrote:

Sorry .. you can call me Kim.

Yes. I know Mark suggested a custom authenticator .. but how would it help me?

The basic thing which i need is simple.
In the login module, i need access to session, request objects ..
How can having a custom authenticator help me?

What i need is a simple API in the login module to get these objects.
Think of it this way. There's a callback for username and password.
A simple solution is to have a callback for those session, request objects.

Now i know that the standard API security doesn't have this.
Maybe Tomcat can provide this API .. a callback to get this object.

By the way, you mentioned about it's more complicated than that.
Sure.

But here's the point.
The need here is basic and is the most fundamental thing used in any web 
application to do authentication and is used by all world wide application to 
do authentication.


But what you're asking it to do goes way beyond authentication.  All
authentication does is tell you if a user should be allowed to access
certain resources.  Nothing more.  Asking it to tell you why they are
not allowed to access it is an additional function that can hurt your
security.




Sure, issue of security etc. But your are forgoing the fundamental on account 
of that.

Think of it this way.

You've build some really good math algorithm to solve some advanced issue while 
all i need is 1+1 = 2 and that is not achievable.


Actually, the better analogy is that there is an application that can
tell you whether or not 1+1=2, and you're asking it to explain why the
numbers they entered don't total up to 2.




I would get the fundamental rights first before moving on to more advanced 
needs like TLS certificate etc.

That's why when i started looking at this issue, well lots of complaints on 
this. Just google it.

Just my thoughts.



Date: Tue, 19 May 2015 09:10:57 -0400
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: Tomcat valve JAAS : form error page displayed first before 
response reaches back to Tomcat valve

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ming Yap,

(Please let me know if I'm using your given name properly... you
haven't identified yourself in the body of your messages, so I only
have your email address for identification purposes. I wouldn't want
to be calling you by the wrong name.)

On 5/18/15 6:23 PM, Kim Ming Yap wrote:

I think Tomcat should provide interfaces for different scenarios
.. that's my opinion.


Tomcat can't dictate the JAAS interfaces. It can only implement and/or
call them. You are right that Tomcat might be able to provide some
convenience items for you, but you'd have to be a bit more specific
about what you'd like.


So coming back to my web form-based authentication problem, is
there a solution to it?


Mark suggested a custom Authenticator. I'd start by looking at one of
the existing authenticators -- depending upon the authenticator you
are currently using (likely FormAuthenticator, based upon your initial
post).

Note that FormAuthenticator.authenticate is probably much more
complicated that you imagined.

- -chris


Date: Mon, 18 May 2015 18:01:31 -0400 From:
ch...@christopherschultz.net To: users@tomcat.apache.org Subject:
Re: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve


Ming Yap,

On 5/18/15 4:56 PM, Kim Ming Yap wrote:

Now here's comes to crucial point and question when comes to
JAAS.

I know the benefit of JAAS - a pluggable authentication and
authorization module.

Why and in JavaEE's name have a JAAS realm (eg in Tomcat)
where th

RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Kim Ming Yap]

You said ..

"> Actually, the better analogy is that there is an application that can 
> tell you whether or not 1+1=2, and you're asking it to explain why the 
> numbers they entered don't total up to 2"

when a user account is disabled after exceeded limits retry .. i couldn't 
display "account disabled" but rather "email / password invalid (due to the 
issue below)

the right analogy is .. 

1 (User) +1 (password) = 10 (10 being the incorrect message being displayed due 
to lack of the needed feature).

Sure .. if if i'm the client .. i will ask 1+1 = 10?

That's the issue.

> Date: Tue, 19 May 2015 10:34:48 -0400
> From: dcker...@verizon.net
> To: users@tomcat.apache.org
> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> response reaches back to Tomcat valve
> 
> On 5/19/2015 10:26 AM, Kim Ming Yap wrote:
> > Sorry .. you can call me Kim.
> >
> > Yes. I know Mark suggested a custom authenticator .. but how would it help 
> > me?
> >
> > The basic thing which i need is simple.
> > In the login module, i need access to session, request objects ..
> > How can having a custom authenticator help me?
> >
> > What i need is a simple API in the login module to get these objects.
> > Think of it this way. There's a callback for username and password.
> > A simple solution is to have a callback for those session, request objects.
> >
> > Now i know that the standard API security doesn't have this.
> > Maybe Tomcat can provide this API .. a callback to get this object.
> >
> > By the way, you mentioned about it's more complicated than that.
> > Sure.
> >
> > But here's the point.
> > The need here is basic and is the most fundamental thing used in any web 
> > application to do authentication and is used by all world wide application 
> > to do authentication.
> 
> But what you're asking it to do goes way beyond authentication.  All 
> authentication does is tell you if a user should be allowed to access 
> certain resources.  Nothing more.  Asking it to tell you why they are 
> not allowed to access it is an additional function that can hurt your 
> security.
> 
> 
> >
> > Sure, issue of security etc. But your are forgoing the fundamental on 
> > account of that.
> >
> > Think of it this way.
> >
> > You've build some really good math algorithm to solve some advanced issue 
> > while all i need is 1+1 = 2 and that is not achievable.
> 
> Actually, the better analogy is that there is an application that can 
> tell you whether or not 1+1=2, and you're asking it to explain why the 
> numbers they entered don't total up to 2.
> 
> 
> >
> > I would get the fundamental rights first before moving on to more advanced 
> > needs like TLS certificate etc.
> >
> > That's why when i started looking at this issue, well lots of complaints on 
> > this. Just google it.
> >
> > Just my thoughts.
> >
> >
> >> Date: Tue, 19 May 2015 09:10:57 -0400
> >> From: ch...@christopherschultz.net
> >> To: users@tomcat.apache.org
> >> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> >> response reaches back to Tomcat valve
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> Ming Yap,
> >>
> >> (Please let me know if I'm using your given name properly... you
> >> haven't identified yourself in the body of your messages, so I only
> >> have your email address for identification purposes. I wouldn't want
> >> to be calling you by the wrong name.)
> >>
> >> On 5/18/15 6:23 PM, Kim Ming Yap wrote:
> >>> I think Tomcat should provide interfaces for different scenarios
> >>> .. that's my opinion.
> >>
> >> Tomcat can't dictate the JAAS interfaces. It can only implement and/or
> >> call them. You are right that Tomcat might be able to provide some
> >> convenience items for you, but you'd have to be a bit more specific
> >> about what you'd like.
> >>
> >>> So coming back to my web form-based authentication problem, is
> >>> there a solution to it?
> >>
> >> Mark suggested a custom Authenticator. I'd start by looking at one of
> >> the existing authenticators -- depending upon the authenticator you
> >> are currently using (likely FormAuthenticator, based upon your initial
> >> post).
> >>
> >> Note that FormAuthent

Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[David kerber]

On 5/19/2015 10:26 AM, Kim Ming Yap wrote:

Sorry .. you can call me Kim.

Yes. I know Mark suggested a custom authenticator .. but how would it help me?

The basic thing which i need is simple.
In the login module, i need access to session, request objects ..
How can having a custom authenticator help me?

What i need is a simple API in the login module to get these objects.
Think of it this way. There's a callback for username and password.
A simple solution is to have a callback for those session, request objects.

Now i know that the standard API security doesn't have this.
Maybe Tomcat can provide this API .. a callback to get this object.

By the way, you mentioned about it's more complicated than that.
Sure.

But here's the point.
The need here is basic and is the most fundamental thing used in any web 
application to do authentication and is used by all world wide application to 
do authentication.


But what you're asking it to do goes way beyond authentication.  All 
authentication does is tell you if a user should be allowed to access 
certain resources.  Nothing more.  Asking it to tell you why they are 
not allowed to access it is an additional function that can hurt your 
security.





Sure, issue of security etc. But your are forgoing the fundamental on account 
of that.

Think of it this way.

You've build some really good math algorithm to solve some advanced issue while 
all i need is 1+1 = 2 and that is not achievable.


Actually, the better analogy is that there is an application that can 
tell you whether or not 1+1=2, and you're asking it to explain why the 
numbers they entered don't total up to 2.





I would get the fundamental rights first before moving on to more advanced 
needs like TLS certificate etc.

That's why when i started looking at this issue, well lots of complaints on 
this. Just google it.

Just my thoughts.



Date: Tue, 19 May 2015 09:10:57 -0400
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: Tomcat valve JAAS : form error page displayed first before 
response reaches back to Tomcat valve

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ming Yap,

(Please let me know if I'm using your given name properly... you
haven't identified yourself in the body of your messages, so I only
have your email address for identification purposes. I wouldn't want
to be calling you by the wrong name.)

On 5/18/15 6:23 PM, Kim Ming Yap wrote:

I think Tomcat should provide interfaces for different scenarios
.. that's my opinion.


Tomcat can't dictate the JAAS interfaces. It can only implement and/or
call them. You are right that Tomcat might be able to provide some
convenience items for you, but you'd have to be a bit more specific
about what you'd like.


So coming back to my web form-based authentication problem, is
there a solution to it?


Mark suggested a custom Authenticator. I'd start by looking at one of
the existing authenticators -- depending upon the authenticator you
are currently using (likely FormAuthenticator, based upon your initial
post).

Note that FormAuthenticator.authenticate is probably much more
complicated that you imagined.

- -chris


Date: Mon, 18 May 2015 18:01:31 -0400 From:
ch...@christopherschultz.net To: users@tomcat.apache.org Subject:
Re: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve


Ming Yap,

On 5/18/15 4:56 PM, Kim Ming Yap wrote:

Now here's comes to crucial point and question when comes to
JAAS.

I know the benefit of JAAS - a pluggable authentication and
authorization module.

Why and in JavaEE's name have a JAAS realm (eg in Tomcat)
where the loginmodule has no access to those most important
objects - sessions, request etc?


... because JAAS does not require you to be running within a web
context. You can use JAAS in a think client. Or from a
command-line client. Or whatever. In those cases, what would you
use for the request or session?


I did a bit of research .. hence other web container like
JBoss, Oracle WebLogic has to build an extended version of
their authentication module to capture those important
objects ..

I just don't comprehend this.This is mind boggling.


Pluggable authentication and authorization is kind of an
unattainable goal when you want it to work across any use case. You
just happen to be thinking of the web-based authentication use
case, here, and it's not matching up with your expectations.

What if you wanted to use some information about a TLS certificate
for authentication? Does the JAAS module now need to have access to
the X.509 certificate as well? What about a Smart Card? Where does
that fit into your web-based view of JAAS?

It's just more complicated than you think, unfortunately.


I have spent almost 4 weeks on trying to solve this basic
problem when comes to form based authentication using JAAS.

1. Val

RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Kim Ming Yap]

Sorry .. you can call me Kim.

Yes. I know Mark suggested a custom authenticator .. but how would it help me?

The basic thing which i need is simple.
In the login module, i need access to session, request objects .. 
How can having a custom authenticator help me?

What i need is a simple API in the login module to get these objects.
Think of it this way. There's a callback for username and password.
A simple solution is to have a callback for those session, request objects.

Now i know that the standard API security doesn't have this.
Maybe Tomcat can provide this API .. a callback to get this object.

By the way, you mentioned about it's more complicated than that.
Sure.

But here's the point.
The need here is basic and is the most fundamental thing used in any web 
application to do authentication and is used by all world wide application to 
do authentication.

Sure, issue of security etc. But your are forgoing the fundamental on account 
of that.

Think of it this way.

You've build some really good math algorithm to solve some advanced issue while 
all i need is 1+1 = 2 and that is not achievable.

I would get the fundamental rights first before moving on to more advanced 
needs like TLS certificate etc.

That's why when i started looking at this issue, well lots of complaints on 
this. Just google it.

Just my thoughts.


> Date: Tue, 19 May 2015 09:10:57 -0400
> From: ch...@christopherschultz.net
> To: users@tomcat.apache.org
> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> response reaches back to Tomcat valve
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Ming Yap,
> 
> (Please let me know if I'm using your given name properly... you
> haven't identified yourself in the body of your messages, so I only
> have your email address for identification purposes. I wouldn't want
> to be calling you by the wrong name.)
> 
> On 5/18/15 6:23 PM, Kim Ming Yap wrote:
> > I think Tomcat should provide interfaces for different scenarios
> > .. that's my opinion.
> 
> Tomcat can't dictate the JAAS interfaces. It can only implement and/or
> call them. You are right that Tomcat might be able to provide some
> convenience items for you, but you'd have to be a bit more specific
> about what you'd like.
> 
> > So coming back to my web form-based authentication problem, is
> > there a solution to it?
> 
> Mark suggested a custom Authenticator. I'd start by looking at one of
> the existing authenticators -- depending upon the authenticator you
> are currently using (likely FormAuthenticator, based upon your initial
> post).
> 
> Note that FormAuthenticator.authenticate is probably much more
> complicated that you imagined.
> 
> - -chris
> 
> >> Date: Mon, 18 May 2015 18:01:31 -0400 From:
> >> ch...@christopherschultz.net To: users@tomcat.apache.org Subject:
> >> Re: Tomcat valve JAAS : form error page displayed first before
> >> response reaches back to Tomcat valve
> >> 
> > Ming Yap,
> > 
> > On 5/18/15 4:56 PM, Kim Ming Yap wrote:
> >>>> Now here's comes to crucial point and question when comes to
> >>>> JAAS.
> >>>> 
> >>>> I know the benefit of JAAS - a pluggable authentication and 
> >>>> authorization module.
> >>>> 
> >>>> Why and in JavaEE's name have a JAAS realm (eg in Tomcat)
> >>>> where the loginmodule has no access to those most important
> >>>> objects - sessions, request etc?
> > 
> > ... because JAAS does not require you to be running within a web 
> > context. You can use JAAS in a think client. Or from a
> > command-line client. Or whatever. In those cases, what would you
> > use for the request or session?
> > 
> >>>> I did a bit of research .. hence other web container like
> >>>> JBoss, Oracle WebLogic has to build an extended version of
> >>>> their authentication module to capture those important
> >>>> objects ..
> >>>> 
> >>>> I just don't comprehend this.This is mind boggling.
> > 
> > Pluggable authentication and authorization is kind of an
> > unattainable goal when you want it to work across any use case. You
> > just happen to be thinking of the web-based authentication use
> > case, here, and it's not matching up with your expectations.
> > 
> > What if you wanted to use some information about a TLS certificate
> > for authentication? Does the JAAS module now need to have access to
> > the X.509 certificate as well? What about a Smart Card? Where does
> >

Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ming Yap,

(Please let me know if I'm using your given name properly... you
haven't identified yourself in the body of your messages, so I only
have your email address for identification purposes. I wouldn't want
to be calling you by the wrong name.)

On 5/18/15 6:23 PM, Kim Ming Yap wrote:
> I think Tomcat should provide interfaces for different scenarios
> .. that's my opinion.

Tomcat can't dictate the JAAS interfaces. It can only implement and/or
call them. You are right that Tomcat might be able to provide some
convenience items for you, but you'd have to be a bit more specific
about what you'd like.

> So coming back to my web form-based authentication problem, is
> there a solution to it?

Mark suggested a custom Authenticator. I'd start by looking at one of
the existing authenticators -- depending upon the authenticator you
are currently using (likely FormAuthenticator, based upon your initial
post).

Note that FormAuthenticator.authenticate is probably much more
complicated that you imagined.

- -chris

>> Date: Mon, 18 May 2015 18:01:31 -0400 From:
>> ch...@christopherschultz.net To: users@tomcat.apache.org Subject:
>> Re: Tomcat valve JAAS : form error page displayed first before
>> response reaches back to Tomcat valve
>> 
> Ming Yap,
> 
> On 5/18/15 4:56 PM, Kim Ming Yap wrote:
>>>> Now here's comes to crucial point and question when comes to
>>>> JAAS.
>>>> 
>>>> I know the benefit of JAAS - a pluggable authentication and 
>>>> authorization module.
>>>> 
>>>> Why and in JavaEE's name have a JAAS realm (eg in Tomcat)
>>>> where the loginmodule has no access to those most important
>>>> objects - sessions, request etc?
> 
> ... because JAAS does not require you to be running within a web 
> context. You can use JAAS in a think client. Or from a
> command-line client. Or whatever. In those cases, what would you
> use for the request or session?
> 
>>>> I did a bit of research .. hence other web container like
>>>> JBoss, Oracle WebLogic has to build an extended version of
>>>> their authentication module to capture those important
>>>> objects ..
>>>> 
>>>> I just don't comprehend this.This is mind boggling.
> 
> Pluggable authentication and authorization is kind of an
> unattainable goal when you want it to work across any use case. You
> just happen to be thinking of the web-based authentication use
> case, here, and it's not matching up with your expectations.
> 
> What if you wanted to use some information about a TLS certificate
> for authentication? Does the JAAS module now need to have access to
> the X.509 certificate as well? What about a Smart Card? Where does
> that fit into your web-based view of JAAS?
> 
> It's just more complicated than you think, unfortunately.
> 
>>>> I have spent almost 4 weeks on trying to solve this basic
>>>> problem when comes to form based authentication using JAAS.
>>>> 
>>>> 1. Valid credential -> no issue2. Credential disabled due to
>>>> gt 3 retry -> This message propagate to the error page3.
>>>> Invalid user id -> This message propagate to error page4.
>>>> Invalid password -> This message propagate to error page
> 
> You should do some reading about user-enumeration vulnerabilities
> and similar things. You probably don't want to give this kind of 
> information to a user. Hint: the user might be an adversary, and
> any information you give them them is something they can use to
> gain access to your system.
> 
> For example: if I enter ob...@whitehouse.gov as my username and
> you tell me "user does not exist", I can keep trying usernames
> until I get one that does exist. Great, now I know the user exists
> and I can keep trying passwords until I get in. If you tell me
> "credentials disabled", then I will know when I've tripped some
> kind of maximum login-attempt trigger that will (likely) disable
> the user for a while. So, I'll adjust my attack strategy so that I
> only try each user 3 times because I know that after that, they
> will be disabled.
> 
> If you have a hard business requirement to tell the user why they 
> aren't being permitted to login, you might want to go back to
> whoever wrote those requirements and ask them to review them from a
> security perspective.
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-u

Re: RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[l...@bsoft.com.cn]

good question.lol



l...@bsoft.com.cn
 
From: Kim Ming Yap
Date: 2015-05-19 06:23
To: Tomcat Users List
Subject: RE: Tomcat valve JAAS : form error page displayed first before 
response reaches back to Tomcat valve
I think Tomcat should provide interfaces for different scenarios .. that's my 
opinion.
So coming back to my web form-based authentication problem, is there a solution 
to it?
 
I still want to solve my problem 
Please advice.Thanks.
 
> Date: Mon, 18 May 2015 18:01:31 -0400
> From: ch...@christopherschultz.net
> To: users@tomcat.apache.org
> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> response reaches back to Tomcat valve
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Ming Yap,
> 
> On 5/18/15 4:56 PM, Kim Ming Yap wrote:
> > Now here's comes to crucial point and question when comes to JAAS.
> > 
> > I know the benefit of JAAS - a pluggable authentication and 
> > authorization module.
> > 
> > Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where
> > the loginmodule has no access to those most important objects -
> > sessions, request etc?
> 
> ... because JAAS does not require you to be running within a web
> context. You can use JAAS in a think client. Or from a command-line
> client. Or whatever. In those cases, what would you use for the
> request or session?
> 
> > I did a bit of research .. hence other web container like JBoss, 
> > Oracle WebLogic has to build an extended version of their 
> > authentication module to capture those important objects ..
> > 
> > I just don't comprehend this.This is mind boggling.
> 
> Pluggable authentication and authorization is kind of an unattainable
> goal when you want it to work across any use case. You just happen to
> be thinking of the web-based authentication use case, here, and it's
> not matching up with your expectations.
> 
> What if you wanted to use some information about a TLS certificate for
> authentication? Does the JAAS module now need to have access to the
> X.509 certificate as well? What about a Smart Card? Where does that
> fit into your web-based view of JAAS?
> 
> It's just more complicated than you think, unfortunately.
> 
> > I have spent almost 4 weeks on trying to solve this basic problem 
> > when comes to form based authentication using JAAS.
> > 
> > 1. Valid credential -> no issue2. Credential disabled due to gt 3 
> > retry -> This message propagate to the error page3. Invalid user
> > id -> This message propagate to error page4. Invalid password ->
> > This message propagate to error page
> 
> You should do some reading about user-enumeration vulnerabilities and
> similar things. You probably don't want to give this kind of
> information to a user. Hint: the user might be an adversary, and any
> information you give them them is something they can use to gain
> access to your system.
> 
> For example: if I enter ob...@whitehouse.gov as my username and you
> tell me "user does not exist", I can keep trying usernames until I get
> one that does exist. Great, now I know the user exists and I can keep
> trying passwords until I get in. If you tell me "credentials
> disabled", then I will know when I've tripped some kind of maximum
> login-attempt trigger that will (likely) disable the user for a while.
> So, I'll adjust my attack strategy so that I only try each user 3
> times because I know that after that, they will be disabled.
> 
> If you have a hard business requirement to tell the user why they
> aren't being permitted to login, you might want to go back to whoever
> wrote those requirements and ask them to review them from a security
> perspective.
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
> 
> iQIcBAEBCAAGBQJVWmE7AAoJEBzwKT+lPKRYLHsP/0SjF8xJlXoZUPLRZVKAvJ9U
> Lf4c5eokEFOjQdbMx4e3vLnTfYK2dWnq0d1Te3n+Zk6fWahy4ijiHHZsdvsQxHCt
> VDFmXZe6FcBu1bFzcU9JNnr2RqRDEBd3St7wWlReB49LpgQaXh3jvKQgPK67ChR9
> K0kBAgzV9BRXzKRLjkEHhC+Q3jFgzmd2J3HerDCgKB6jSFw6dn8NdZJqCfAIAG6R
> xtbYvryRrQEVaMNs0Z0eDRsRy3iTAZAA1FZOUGSxVfAWapcj12RtnbKfB6tX+wc1
> ghy6ZZW3efQSirvZ4BbYqsptBYzsA3oU25zbJG5jdz170okYLphx9vbtbP7wFQFJ
> CPANIDWLj/aTKCch+SCOMLlOXCBAR69HobDG3Tzi0riaeZAxNuBV61SZjIUhA+Bl
> tVfihOoLxZQcPk7s4VoR4w1SD7nBqMSkzbwTJujbjM7UKi311lRr6LqO6DvYEsg1
> eX4qpKELndniJ035wrZXjbGtMS6JWDRjmeIJkVc0+6XsdMJ7c1bzaImfJg9dv6x9
> ZlKpiTbW4n5jC6jrvu5elRuAudf0Me467y9JDZq6ujMmcPVr3BcQQKb4cHXnPRzh
> BpHqXcn19LZGatyx0wpz8nf5ZjHQiyeaWOgSjLyk8yJXXz6EyA4SZ8Ndi8O5Z/tb
> kgPkqUPohzH02HWcg6E2
> =q5gu
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
 

RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Kim Ming Yap]

I think Tomcat should provide interfaces for different scenarios .. that's my 
opinion.
So coming back to my web form-based authentication problem, is there a solution 
to it?

I still want to solve my problem 😏
Please advice.Thanks.

> Date: Mon, 18 May 2015 18:01:31 -0400
> From: ch...@christopherschultz.net
> To: users@tomcat.apache.org
> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> response reaches back to Tomcat valve
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Ming Yap,
> 
> On 5/18/15 4:56 PM, Kim Ming Yap wrote:
> > Now here's comes to crucial point and question when comes to JAAS.
> > 
> > I know the benefit of JAAS - a pluggable authentication and 
> > authorization module.
> > 
> > Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where
> > the loginmodule has no access to those most important objects -
> > sessions, request etc?
> 
> ... because JAAS does not require you to be running within a web
> context. You can use JAAS in a think client. Or from a command-line
> client. Or whatever. In those cases, what would you use for the
> request or session?
> 
> > I did a bit of research .. hence other web container like JBoss, 
> > Oracle WebLogic has to build an extended version of their 
> > authentication module to capture those important objects ..
> > 
> > I just don't comprehend this.This is mind boggling.
> 
> Pluggable authentication and authorization is kind of an unattainable
> goal when you want it to work across any use case. You just happen to
> be thinking of the web-based authentication use case, here, and it's
> not matching up with your expectations.
> 
> What if you wanted to use some information about a TLS certificate for
> authentication? Does the JAAS module now need to have access to the
> X.509 certificate as well? What about a Smart Card? Where does that
> fit into your web-based view of JAAS?
> 
> It's just more complicated than you think, unfortunately.
> 
> > I have spent almost 4 weeks on trying to solve this basic problem 
> > when comes to form based authentication using JAAS.
> > 
> > 1. Valid credential -> no issue2. Credential disabled due to gt 3 
> > retry -> This message propagate to the error page3. Invalid user
> > id -> This message propagate to error page4. Invalid password ->
> > This message propagate to error page
> 
> You should do some reading about user-enumeration vulnerabilities and
> similar things. You probably don't want to give this kind of
> information to a user. Hint: the user might be an adversary, and any
> information you give them them is something they can use to gain
> access to your system.
> 
> For example: if I enter ob...@whitehouse.gov as my username and you
> tell me "user does not exist", I can keep trying usernames until I get
> one that does exist. Great, now I know the user exists and I can keep
> trying passwords until I get in. If you tell me "credentials
> disabled", then I will know when I've tripped some kind of maximum
> login-attempt trigger that will (likely) disable the user for a while.
> So, I'll adjust my attack strategy so that I only try each user 3
> times because I know that after that, they will be disabled.
> 
> If you have a hard business requirement to tell the user why they
> aren't being permitted to login, you might want to go back to whoever
> wrote those requirements and ask them to review them from a security
> perspective.
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
> 
> iQIcBAEBCAAGBQJVWmE7AAoJEBzwKT+lPKRYLHsP/0SjF8xJlXoZUPLRZVKAvJ9U
> Lf4c5eokEFOjQdbMx4e3vLnTfYK2dWnq0d1Te3n+Zk6fWahy4ijiHHZsdvsQxHCt
> VDFmXZe6FcBu1bFzcU9JNnr2RqRDEBd3St7wWlReB49LpgQaXh3jvKQgPK67ChR9
> K0kBAgzV9BRXzKRLjkEHhC+Q3jFgzmd2J3HerDCgKB6jSFw6dn8NdZJqCfAIAG6R
> xtbYvryRrQEVaMNs0Z0eDRsRy3iTAZAA1FZOUGSxVfAWapcj12RtnbKfB6tX+wc1
> ghy6ZZW3efQSirvZ4BbYqsptBYzsA3oU25zbJG5jdz170okYLphx9vbtbP7wFQFJ
> CPANIDWLj/aTKCch+SCOMLlOXCBAR69HobDG3Tzi0riaeZAxNuBV61SZjIUhA+Bl
> tVfihOoLxZQcPk7s4VoR4w1SD7nBqMSkzbwTJujbjM7UKi311lRr6LqO6DvYEsg1
> eX4qpKELndniJ035wrZXjbGtMS6JWDRjmeIJkVc0+6XsdMJ7c1bzaImfJg9dv6x9
> ZlKpiTbW4n5jC6jrvu5elRuAudf0Me467y9JDZq6ujMmcPVr3BcQQKb4cHXnPRzh
> BpHqXcn19LZGatyx0wpz8nf5ZjHQiyeaWOgSjLyk8yJXXz6EyA4SZ8Ndi8O5Z/tb
> kgPkqUPohzH02HWcg6E2
> =q5gu
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
  

Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ming Yap,

On 5/18/15 4:56 PM, Kim Ming Yap wrote:
> Now here's comes to crucial point and question when comes to JAAS.
> 
> I know the benefit of JAAS - a pluggable authentication and 
> authorization module.
> 
> Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where
> the loginmodule has no access to those most important objects -
> sessions, request etc?

... because JAAS does not require you to be running within a web
context. You can use JAAS in a think client. Or from a command-line
client. Or whatever. In those cases, what would you use for the
request or session?

> I did a bit of research .. hence other web container like JBoss, 
> Oracle WebLogic has to build an extended version of their 
> authentication module to capture those important objects ..
> 
> I just don't comprehend this.This is mind boggling.

Pluggable authentication and authorization is kind of an unattainable
goal when you want it to work across any use case. You just happen to
be thinking of the web-based authentication use case, here, and it's
not matching up with your expectations.

What if you wanted to use some information about a TLS certificate for
authentication? Does the JAAS module now need to have access to the
X.509 certificate as well? What about a Smart Card? Where does that
fit into your web-based view of JAAS?

It's just more complicated than you think, unfortunately.

> I have spent almost 4 weeks on trying to solve this basic problem 
> when comes to form based authentication using JAAS.
> 
> 1. Valid credential -> no issue2. Credential disabled due to gt 3 
> retry -> This message propagate to the error page3. Invalid user
> id -> This message propagate to error page4. Invalid password ->
> This message propagate to error page

You should do some reading about user-enumeration vulnerabilities and
similar things. You probably don't want to give this kind of
information to a user. Hint: the user might be an adversary, and any
information you give them them is something they can use to gain
access to your system.

For example: if I enter ob...@whitehouse.gov as my username and you
tell me "user does not exist", I can keep trying usernames until I get
one that does exist. Great, now I know the user exists and I can keep
trying passwords until I get in. If you tell me "credentials
disabled", then I will know when I've tripped some kind of maximum
login-attempt trigger that will (likely) disable the user for a while.
So, I'll adjust my attack strategy so that I only try each user 3
times because I know that after that, they will be disabled.

If you have a hard business requirement to tell the user why they
aren't being permitted to login, you might want to go back to whoever
wrote those requirements and ask them to review them from a security
perspective.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVWmE7AAoJEBzwKT+lPKRYLHsP/0SjF8xJlXoZUPLRZVKAvJ9U
Lf4c5eokEFOjQdbMx4e3vLnTfYK2dWnq0d1Te3n+Zk6fWahy4ijiHHZsdvsQxHCt
VDFmXZe6FcBu1bFzcU9JNnr2RqRDEBd3St7wWlReB49LpgQaXh3jvKQgPK67ChR9
K0kBAgzV9BRXzKRLjkEHhC+Q3jFgzmd2J3HerDCgKB6jSFw6dn8NdZJqCfAIAG6R
xtbYvryRrQEVaMNs0Z0eDRsRy3iTAZAA1FZOUGSxVfAWapcj12RtnbKfB6tX+wc1
ghy6ZZW3efQSirvZ4BbYqsptBYzsA3oU25zbJG5jdz170okYLphx9vbtbP7wFQFJ
CPANIDWLj/aTKCch+SCOMLlOXCBAR69HobDG3Tzi0riaeZAxNuBV61SZjIUhA+Bl
tVfihOoLxZQcPk7s4VoR4w1SD7nBqMSkzbwTJujbjM7UKi311lRr6LqO6DvYEsg1
eX4qpKELndniJ035wrZXjbGtMS6JWDRjmeIJkVc0+6XsdMJ7c1bzaImfJg9dv6x9
ZlKpiTbW4n5jC6jrvu5elRuAudf0Me467y9JDZq6ujMmcPVr3BcQQKb4cHXnPRzh
BpHqXcn19LZGatyx0wpz8nf5ZjHQiyeaWOgSjLyk8yJXXz6EyA4SZ8Ndi8O5Z/tb
kgPkqUPohzH02HWcg6E2
=q5gu
-END PGP SIGNATURE-

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

RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Kim Ming Yap]

ok. cool :) i understand better.
Now here's comes to crucial point and question when comes to JAAS.
I know the benefit of JAAS - a pluggable authentication and authorization 
module.
Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where the loginmodule 
has no access to those most important objects - sessions, request etc?
I did a bit of research .. hence other web container like JBoss, Oracle 
WebLogic has to build an extended version of their authentication module to 
capture those important objects ..
I just don't comprehend this.This is mind boggling ..
I have spent almost 4 weeks on trying to solve this basic problem when comes to 
form based authentication using JAAS.
1. Valid credential -> no issue2. Credential disabled due to gt 3 retry -> This 
message propagate to the error page3. Invalid user id -> This message propagate 
to error page4. Invalid password -> This message propagate to error page
There's no way to propagate the above error messages to the error page from 
JAAS login module since this module has no access to those important 
aforementioned objects.
Hence i turn to valve (storing ThreadLocal). But as you can see, the error page 
gets displayed first even before i can store them in the session object.
Without this feature, the only error message i can display is for example:
"Incorrect email or password."
But this is incorrect if the account is disabled.
So i'm just flabbergasted that there's a JAAS module but without access to 
those basic objects used in any web development.
This is beyond mind boggling ..
Any insights?


> Date: Mon, 18 May 2015 16:08:41 -0400
> From: ch...@christopherschultz.net
> To: users@tomcat.apache.org
> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> response reaches back to Tomcat valve
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Ming Yap,
> 
> On 5/18/15 11:43 AM, Kim Ming Yap wrote:
> > so who control the data flow?
> 
> The data is really just a data stream. Anyone dumping data into that
> stream "controls the flow". Any component with access to the
> OutputStream to the client can inject something into it.
> 
> The method call flow doesn't place any restrictions on what each
> component is allowed to put into that OutputStream.
> 
> > Does the data flow has stages just like control flow?
> 
> It's the Wild West: any component can do anything it wants.
> 
> > Or is it just the http web server? As long as there are output
> > stream going out .. the http web server will server those output
> > stream to the client's browser?
> 
> Exactly.
> 
> > Basically no control stages when comes to data flow?
> 
> Correct. There are basically two stages:
> 
> 1. Before the response has been "committed"
> 2. After the response has been "committed"
> 
> The "committment" of the response occurs when either of the following
> things happen:
> 
>   a. The response buffer fills up (container flushes buffer)
>   b. A component explicitly flushes the response buffer
> 
> Before the response has been committed, you can add/modify/remove
> response headers, change the response status code (e.g. 200 OK),
> request the creation of an HttpSession, and a few other things. After
> the response has been committed, you can do none of those things: only
> sending bytes to the response stream will work after that.
> 
> But again, the only things that triggers the "commit" of the response
> if the response buffer filling up (or an explicit flush() call). Any
> component can cause that event to occur, and no other components are
> notified that it's about to happen.
> 
> You can check to see if the response has been committed, but you can't
> do anything effective to stop it.
> 
> - -chris
> 
> >> Date: Mon, 18 May 2015 14:54:24 +0100 From: ma...@apache.org To:
> >> users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form
> >> error page displayed first before response reaches back to Tomcat
> >> valve
> >> 
> >> On 18/05/2015 13:57, Kim Ming Yap wrote:
> >>> Wow .. that really confuses me.
> >>> 
> >>> I've studied the Java EE component and the basic understanding
> >>> of flow is as follows (if i do not flush the data)
> >>> 
> >>> client request --> web container (encapsulate request/response)
> >>> --> filter (contain request/response object) --> Servlet (JSP)
> >>> --> filter (request / response object here can be modified here
> >>> for eventual display on browser) --> client browser
> >>> 
> >>> 

Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ming Yap,

On 5/18/15 11:43 AM, Kim Ming Yap wrote:
> so who control the data flow?

The data is really just a data stream. Anyone dumping data into that
stream "controls the flow". Any component with access to the
OutputStream to the client can inject something into it.

The method call flow doesn't place any restrictions on what each
component is allowed to put into that OutputStream.

> Does the data flow has stages just like control flow?

It's the Wild West: any component can do anything it wants.

> Or is it just the http web server? As long as there are output
> stream going out .. the http web server will server those output
> stream to the client's browser?

Exactly.

> Basically no control stages when comes to data flow?

Correct. There are basically two stages:

1. Before the response has been "committed"
2. After the response has been "committed"

The "committment" of the response occurs when either of the following
things happen:

  a. The response buffer fills up (container flushes buffer)
  b. A component explicitly flushes the response buffer

Before the response has been committed, you can add/modify/remove
response headers, change the response status code (e.g. 200 OK),
request the creation of an HttpSession, and a few other things. After
the response has been committed, you can do none of those things: only
sending bytes to the response stream will work after that.

But again, the only things that triggers the "commit" of the response
if the response buffer filling up (or an explicit flush() call). Any
component can cause that event to occur, and no other components are
notified that it's about to happen.

You can check to see if the response has been committed, but you can't
do anything effective to stop it.

- -chris

>> Date: Mon, 18 May 2015 14:54:24 +0100 From: ma...@apache.org To:
>> users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form
>> error page displayed first before response reaches back to Tomcat
>> valve
>> 
>> On 18/05/2015 13:57, Kim Ming Yap wrote:
>>> Wow .. that really confuses me.
>>> 
>>> I've studied the Java EE component and the basic understanding
>>> of flow is as follows (if i do not flush the data)
>>> 
>>> client request --> web container (encapsulate request/response)
>>> --> filter (contain request/response object) --> Servlet (JSP)
>>> --> filter (request / response object here can be modified here
>>> for eventual display on browser) --> client browser
>>> 
>>> On the way back the client browser, if i do a break point just
>>> immediately after the dofilter() method and stop there, the JSP
>>> page is not displayed.
>>> 
>>> So if i get your right: 1. If the above is done without
>>> flushing the data .. then yes. That JSP page is not displayed
>>> since i stop at the breakpoint.
>> 
>> Correct. The entire response is contained in the output buffer at
>> that point.
>> 
>>> 2. However if i do a flush before the break point, data will be
>>> send to the client eventhough my code stops at the break
>>> point?
>> 
>> Correct. On the first write to the client, the HTTP Response
>> headers will be written. This is the point at which the response
>> is considered to be committed. The first write may also include
>> some/all of the response body.
>> 
>> Flushing can be explicit (the application calls it) or implicit
>> (the container calls flush because - for example - there is no
>> more space in the output buffer).
>> 
>>> I thought the data flow is part of the control flow ..
>>> 
>>> Gee .. i got this wrong all the while Think i'm seeing the
>>> light ..
>> 
>> Happy to help.
>> 
>> Mark
>> 
>> 
>>> 
>>> 
>>>> Date: Mon, 18 May 2015 13:43:14 +0100 From: ma...@apache.org 
>>>> To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS :
>>>> form error page displayed first before response reaches back
>>>> to Tomcat valve
>>>> 
>>>> On 18/05/2015 13:31, Kim Ming Yap wrote:
>>>>> 
>>>>> Thanks Mark for your suggestion. I'm still confused over
>>>>> the last part where you mentioned that 'i am confusing
>>>>> myself between control and data'. The response object
>>>>> contains output stream (data) to be displayed. Always the
>>>>> case.
>>>> 
>>>> No.
>>>> 
>>>> The response con

RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Kim Ming Yap]

You said 
"The error page will be handled by the webapp or the ErrorReportingValve - both 
of whichh may get called before your Valve depending on how the Valve is 
configured."
How do i ensure that my custom valve is called before the the 
ErrorReportingValve?Is there some settings i can set?

Thanks for your help.

> From: yapk...@hotmail.com
> To: users@tomcat.apache.org
> Subject: RE: Tomcat valve JAAS : form error page displayed first before 
> response reaches back to Tomcat valve
> Date: Mon, 18 May 2015 11:43:02 -0400
> 
> so who control the data flow?
> Does the data flow has stages just like control flow?
> Or is it just the http web server? As long as there are output stream going 
> out .. the http web server will server those output stream to the client's 
> browser?
> Basically no control stages when comes to data flow?
> 
> 
> > Date: Mon, 18 May 2015 14:54:24 +0100
> > From: ma...@apache.org
> > To: users@tomcat.apache.org
> > Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> > response reaches back to Tomcat valve
> > 
> > On 18/05/2015 13:57, Kim Ming Yap wrote:
> > > Wow .. that really confuses me.
> > > 
> > > I've studied the Java EE component and the basic understanding of flow is 
> > > as follows (if i do not flush the data)
> > > 
> > > client request --> web container (encapsulate request/response) --> 
> > > filter (contain request/response object) --> Servlet (JSP) --> filter 
> > > (request / response object here can be modified here for eventual display 
> > > on browser) --> client browser
> > > 
> > > On the way back the client browser, if i do a break point just 
> > > immediately after the dofilter() method and stop there, the JSP page is 
> > > not displayed.
> > > 
> > > So if i get your right:
> > > 1. If the above is done without flushing the data .. then yes. That JSP 
> > > page is not displayed since i stop at the breakpoint.
> > 
> > Correct. The entire response is contained in the output buffer at that
> > point.
> > 
> > > 2. However if i do a flush before the break point, data will be send to 
> > > the client eventhough my code stops at the break point?
> > 
> > Correct. On the first write to the client, the HTTP Response headers
> > will be written. This is the point at which the response is considered
> > to be committed. The first write may also include some/all of the
> > response body.
> > 
> > Flushing can be explicit (the application calls it) or implicit (the
> > container calls flush because - for example - there is no more space in
> > the output buffer).
> > 
> > > I thought the data flow is part of the control flow ..
> > > 
> > > Gee .. i got this wrong all the while
> > > Think i'm seeing the light ..
> > 
> > Happy to help.
> > 
> > Mark
> > 
> > 
> > > 
> > > 
> > >> Date: Mon, 18 May 2015 13:43:14 +0100
> > >> From: ma...@apache.org
> > >> To: users@tomcat.apache.org
> > >> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> > >> response reaches back to Tomcat valve
> > >>
> > >> On 18/05/2015 13:31, Kim Ming Yap wrote:
> > >>>
> > >>> Thanks Mark for your suggestion.
> > >>> I'm still confused over the last part where you mentioned that 'i am 
> > >>> confusing myself between control and data'.
> > >>> The response object contains output stream (data) to be displayed. 
> > >>> Always the case.
> > >>
> > >> No.
> > >>
> > >> The response contains a reference to the output stream. The output
> > >> stream can be flushed to the client *at any point*. There is no
> > >> guarantee that it will "contain the [data] to be displayed".
> > >>
> > >> The (incorrect) sequences you list below describe the control flow. The
> > >> data flow (when the application reads the request body, when the
> > >> application writes the request body and when the request body is written
> > >> to the client) is completely separate.
> > >>
> > >>> If i enter valid credential .. you'll noticed the flow exactly as 
> > >>> indicated on my email (I've traced is using system.out.println)
> > >>>
> > >>> request --> valve --> JAAS --> filter --> JS

RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Kim Ming Yap]

so who control the data flow?
Does the data flow has stages just like control flow?
Or is it just the http web server? As long as there are output stream going out 
.. the http web server will server those output stream to the client's browser?
Basically no control stages when comes to data flow?


> Date: Mon, 18 May 2015 14:54:24 +0100
> From: ma...@apache.org
> To: users@tomcat.apache.org
> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> response reaches back to Tomcat valve
> 
> On 18/05/2015 13:57, Kim Ming Yap wrote:
> > Wow .. that really confuses me.
> > 
> > I've studied the Java EE component and the basic understanding of flow is 
> > as follows (if i do not flush the data)
> > 
> > client request --> web container (encapsulate request/response) --> filter 
> > (contain request/response object) --> Servlet (JSP) --> filter (request / 
> > response object here can be modified here for eventual display on browser) 
> > --> client browser
> > 
> > On the way back the client browser, if i do a break point just immediately 
> > after the dofilter() method and stop there, the JSP page is not displayed.
> > 
> > So if i get your right:
> > 1. If the above is done without flushing the data .. then yes. That JSP 
> > page is not displayed since i stop at the breakpoint.
> 
> Correct. The entire response is contained in the output buffer at that
> point.
> 
> > 2. However if i do a flush before the break point, data will be send to the 
> > client eventhough my code stops at the break point?
> 
> Correct. On the first write to the client, the HTTP Response headers
> will be written. This is the point at which the response is considered
> to be committed. The first write may also include some/all of the
> response body.
> 
> Flushing can be explicit (the application calls it) or implicit (the
> container calls flush because - for example - there is no more space in
> the output buffer).
> 
> > I thought the data flow is part of the control flow ..
> > 
> > Gee .. i got this wrong all the while
> > Think i'm seeing the light ..
> 
> Happy to help.
> 
> Mark
> 
> 
> > 
> > 
> >> Date: Mon, 18 May 2015 13:43:14 +0100
> >> From: ma...@apache.org
> >> To: users@tomcat.apache.org
> >> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> >> response reaches back to Tomcat valve
> >>
> >> On 18/05/2015 13:31, Kim Ming Yap wrote:
> >>>
> >>> Thanks Mark for your suggestion.
> >>> I'm still confused over the last part where you mentioned that 'i am 
> >>> confusing myself between control and data'.
> >>> The response object contains output stream (data) to be displayed. Always 
> >>> the case.
> >>
> >> No.
> >>
> >> The response contains a reference to the output stream. The output
> >> stream can be flushed to the client *at any point*. There is no
> >> guarantee that it will "contain the [data] to be displayed".
> >>
> >> The (incorrect) sequences you list below describe the control flow. The
> >> data flow (when the application reads the request body, when the
> >> application writes the request body and when the request body is written
> >> to the client) is completely separate.
> >>
> >>> If i enter valid credential .. you'll noticed the flow exactly as 
> >>> indicated on my email (I've traced is using system.out.println)
> >>>
> >>> request --> valve --> JAAS --> filter --> JSP  --> response --> filter 
> >>> --> JAAS --> valve --> browser
> >>
> >> Again, no. JAAS does not call the filter. Your valve calls the
> >> Authenticator which calls JAAS and then (via some additional objects)
> >> the Authenticator calls the filter.
> >>
> >> Neither the request nor the response are part of the processing chain.
> >> They are objects that are passed up and down the chain.
> >>
> >>
> >>> If invalid credential ..
> >>>
> >>> request --> valve --> JAAS --> response --> valve (break point and stop 
> >>> here) .. yet JSP error page displayed.
> >>>
> >>> So this is really confusing.
> >>
> >> Take a look at the updated diagrams here:
> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=57282
> >>
> >>> The response always contains data to be di

Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Mark Thomas]

On 18/05/2015 13:57, Kim Ming Yap wrote:
> Wow .. that really confuses me.
> 
> I've studied the Java EE component and the basic understanding of flow is as 
> follows (if i do not flush the data)
> 
> client request --> web container (encapsulate request/response) --> filter 
> (contain request/response object) --> Servlet (JSP) --> filter (request / 
> response object here can be modified here for eventual display on browser) 
> --> client browser
> 
> On the way back the client browser, if i do a break point just immediately 
> after the dofilter() method and stop there, the JSP page is not displayed.
> 
> So if i get your right:
> 1. If the above is done without flushing the data .. then yes. That JSP page 
> is not displayed since i stop at the breakpoint.

Correct. The entire response is contained in the output buffer at that
point.

> 2. However if i do a flush before the break point, data will be send to the 
> client eventhough my code stops at the break point?

Correct. On the first write to the client, the HTTP Response headers
will be written. This is the point at which the response is considered
to be committed. The first write may also include some/all of the
response body.

Flushing can be explicit (the application calls it) or implicit (the
container calls flush because - for example - there is no more space in
the output buffer).

> I thought the data flow is part of the control flow ..
> 
> Gee .. i got this wrong all the while
> Think i'm seeing the light ..

Happy to help.

Mark


> 
> 
>> Date: Mon, 18 May 2015 13:43:14 +0100
>> From: ma...@apache.org
>> To: users@tomcat.apache.org
>> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
>> response reaches back to Tomcat valve
>>
>> On 18/05/2015 13:31, Kim Ming Yap wrote:
>>>
>>> Thanks Mark for your suggestion.
>>> I'm still confused over the last part where you mentioned that 'i am 
>>> confusing myself between control and data'.
>>> The response object contains output stream (data) to be displayed. Always 
>>> the case.
>>
>> No.
>>
>> The response contains a reference to the output stream. The output
>> stream can be flushed to the client *at any point*. There is no
>> guarantee that it will "contain the [data] to be displayed".
>>
>> The (incorrect) sequences you list below describe the control flow. The
>> data flow (when the application reads the request body, when the
>> application writes the request body and when the request body is written
>> to the client) is completely separate.
>>
>>> If i enter valid credential .. you'll noticed the flow exactly as indicated 
>>> on my email (I've traced is using system.out.println)
>>>
>>> request --> valve --> JAAS --> filter --> JSP  --> response --> filter --> 
>>> JAAS --> valve --> browser
>>
>> Again, no. JAAS does not call the filter. Your valve calls the
>> Authenticator which calls JAAS and then (via some additional objects)
>> the Authenticator calls the filter.
>>
>> Neither the request nor the response are part of the processing chain.
>> They are objects that are passed up and down the chain.
>>
>>
>>> If invalid credential ..
>>>
>>> request --> valve --> JAAS --> response --> valve (break point and stop 
>>> here) .. yet JSP error page displayed.
>>>
>>> So this is really confusing.
>>
>> Take a look at the updated diagrams here:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57282
>>
>>> The response always contains data to be displayed on the client browser.
>>
>> No it does not. See comment above re control flow vs data flow.
>>
>>> How did the JSP error page displayed when on its way back to the client 
>>> browser .. i did a break point stop at the valve.
>>
>> See point above re control flow vs data flow.
>>
>> Mark
>>
>>
>>>
>>> Hm ..
>>>
>>>
>>>> Date: Mon, 18 May 2015 11:14:19 +0100
>>>> From: ma...@apache.org
>>>> To: users@tomcat.apache.org
>>>> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
>>>> response reaches back to Tomcat valve
>>>>
>>>> On 17/05/2015 23:44, Kim Ming Yap wrote:
>>>>> Hi,I'm building a website using form based authentication integrating 
>>>>> with JAAS for user based authentication. I don't have issue when a 
>>>>> successful 

RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Kim Ming Yap]

Wow .. that really confuses me.

I've studied the Java EE component and the basic understanding of flow is as 
follows (if i do not flush the data)

client request --> web container (encapsulate request/response) --> filter 
(contain request/response object) --> Servlet (JSP) --> filter (request / 
response object here can be modified here for eventual display on browser) --> 
client browser

On the way back the client browser, if i do a break point just immediately 
after the dofilter() method and stop there, the JSP page is not displayed.

So if i get your right:
1. If the above is done without flushing the data .. then yes. That JSP page is 
not displayed since i stop at the breakpoint.
2. However if i do a flush before the break point, data will be send to the 
client eventhough my code stops at the break point?

I thought the data flow is part of the control flow ..

Gee .. i got this wrong all the while
Think i'm seeing the light ..


> Date: Mon, 18 May 2015 13:43:14 +0100
> From: ma...@apache.org
> To: users@tomcat.apache.org
> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> response reaches back to Tomcat valve
> 
> On 18/05/2015 13:31, Kim Ming Yap wrote:
> > 
> > Thanks Mark for your suggestion.
> > I'm still confused over the last part where you mentioned that 'i am 
> > confusing myself between control and data'.
> > The response object contains output stream (data) to be displayed. Always 
> > the case.
> 
> No.
> 
> The response contains a reference to the output stream. The output
> stream can be flushed to the client *at any point*. There is no
> guarantee that it will "contain the [data] to be displayed".
> 
> The (incorrect) sequences you list below describe the control flow. The
> data flow (when the application reads the request body, when the
> application writes the request body and when the request body is written
> to the client) is completely separate.
> 
> > If i enter valid credential .. you'll noticed the flow exactly as indicated 
> > on my email (I've traced is using system.out.println)
> > 
> > request --> valve --> JAAS --> filter --> JSP  --> response --> filter --> 
> > JAAS --> valve --> browser
> 
> Again, no. JAAS does not call the filter. Your valve calls the
> Authenticator which calls JAAS and then (via some additional objects)
> the Authenticator calls the filter.
> 
> Neither the request nor the response are part of the processing chain.
> They are objects that are passed up and down the chain.
> 
> 
> > If invalid credential ..
> > 
> > request --> valve --> JAAS --> response --> valve (break point and stop 
> > here) .. yet JSP error page displayed.
> > 
> > So this is really confusing.
> 
> Take a look at the updated diagrams here:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57282
> 
> > The response always contains data to be displayed on the client browser.
> 
> No it does not. See comment above re control flow vs data flow.
> 
> > How did the JSP error page displayed when on its way back to the client 
> > browser .. i did a break point stop at the valve.
> 
> See point above re control flow vs data flow.
> 
> Mark
> 
> 
> > 
> > Hm ..
> > 
> > 
> >> Date: Mon, 18 May 2015 11:14:19 +0100
> >> From: ma...@apache.org
> >> To: users@tomcat.apache.org
> >> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> >> response reaches back to Tomcat valve
> >>
> >> On 17/05/2015 23:44, Kim Ming Yap wrote:
> >>> Hi,I'm building a website using form based authentication integrating 
> >>> with JAAS for user based authentication. I don't have issue when a 
> >>> successful credential is authenticated. Rather I'm having difficulty 
> >>> understanding the flow of JAAS back to the client should the form based 
> >>> authentication failed.
> >>> SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
> >>> OBJECTIVE:Custom error captured in JAAS login module to propagate to 
> >>> error page
> >>
> >> You are unlikely to get much help from Tomcat with this since
> >> propagating back custom errors is considered poor security practise (an
> >> attacker should not be able to tell why authentication failed).
> >>
> >>> BASIC UNDERSTANDING:
> >>> The Tomcat JAAS layer is not integrated with the web container layer. 
> >>> Hence the former does not have access to request, session etc.
> >>
&g

Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Mark Thomas]

On 18/05/2015 13:31, Kim Ming Yap wrote:
> 
> Thanks Mark for your suggestion.
> I'm still confused over the last part where you mentioned that 'i am 
> confusing myself between control and data'.
> The response object contains output stream (data) to be displayed. Always the 
> case.

No.

The response contains a reference to the output stream. The output
stream can be flushed to the client *at any point*. There is no
guarantee that it will "contain the [data] to be displayed".

The (incorrect) sequences you list below describe the control flow. The
data flow (when the application reads the request body, when the
application writes the request body and when the request body is written
to the client) is completely separate.

> If i enter valid credential .. you'll noticed the flow exactly as indicated 
> on my email (I've traced is using system.out.println)
> 
> request --> valve --> JAAS --> filter --> JSP  --> response --> filter --> 
> JAAS --> valve --> browser

Again, no. JAAS does not call the filter. Your valve calls the
Authenticator which calls JAAS and then (via some additional objects)
the Authenticator calls the filter.

Neither the request nor the response are part of the processing chain.
They are objects that are passed up and down the chain.


> If invalid credential ..
> 
> request --> valve --> JAAS --> response --> valve (break point and stop here) 
> .. yet JSP error page displayed.
> 
> So this is really confusing.

Take a look at the updated diagrams here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57282

> The response always contains data to be displayed on the client browser.

No it does not. See comment above re control flow vs data flow.

> How did the JSP error page displayed when on its way back to the client 
> browser .. i did a break point stop at the valve.

See point above re control flow vs data flow.

Mark


> 
> Hm ..
> 
> 
>> Date: Mon, 18 May 2015 11:14:19 +0100
>> From: ma...@apache.org
>> To: users@tomcat.apache.org
>> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
>> response reaches back to Tomcat valve
>>
>> On 17/05/2015 23:44, Kim Ming Yap wrote:
>>> Hi,I'm building a website using form based authentication integrating with 
>>> JAAS for user based authentication. I don't have issue when a successful 
>>> credential is authenticated. Rather I'm having difficulty understanding the 
>>> flow of JAAS back to the client should the form based authentication failed.
>>> SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
>>> OBJECTIVE:Custom error captured in JAAS login module to propagate to error 
>>> page
>>
>> You are unlikely to get much help from Tomcat with this since
>> propagating back custom errors is considered poor security practise (an
>> attacker should not be able to tell why authentication failed).
>>
>>> BASIC UNDERSTANDING:
>>> The Tomcat JAAS layer is not integrated with the web container layer. Hence 
>>> the former does not have access to request, session etc.
>>
>> JAAS is integrated as a Realm - i.e. something that validates
>> credentials provided by an Authenticator. The Authenticator has full
>> access to the request and the response. You may want to consider a
>> custom Authenticator.
>>
>>> SOLUTION:
>>> Using ThreadLocal which capture the custom error message in JAAS layer to 
>>> be used when the flow reaches back to the custom valve on the way back to 
>>> the browser.
>>
>> You need to be careful you don't trigger memory leaks when using
>> ThreadLocals.
>>
>>> PROBELM:Understanding of basic request/response flow involving Tomcat and 
>>> JAAS
>>> a. request --> valve --> JAAS --> Filter --> Servlet/JSPb. response <-- 
>>> valve (**) <-- JAAS <-- Filter <-- Servlet/JSP
>>
>> I suspect that order is wrong.
>>
>> JAAS is called by the Authenticator (which is a valve). The
>> Authenticator then calls the Filter (via a few other layers).
>>
>> You might want to check the ordering of your valve and the Authenticator.
>>
>>> (refer to above clause b)ThreadLocal in the JAAS layer managed to capture 
>>> the custom error message and it i managed to print it after the getNext() 
>>> method of the custom valve. Thought of adding this custom error as an 
>>> attribute in the session object.
>>> However I noticed that the error page is already displayed before i could 
>>> add this cusom error (immediately after the getNext 

RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Kim Ming Yap]

Thanks Mark for your suggestion.
I'm still confused over the last part where you mentioned that 'i am confusing 
myself between control and data'.
The response object contains output stream (data) to be displayed. Always the 
case.

If i enter valid credential .. you'll noticed the flow exactly as indicated on 
my email (I've traced is using system.out.println)

request --> valve --> JAAS --> filter --> JSP  --> response --> filter --> JAAS 
--> valve --> browser

If invalid credential ..

request --> valve --> JAAS --> response --> valve (break point and stop here) 
.. yet JSP error page displayed.

So this is really confusing.

The response always contains data to be displayed on the client browser.
How did the JSP error page displayed when on its way back to the client browser 
.. i did a break point stop at the valve.

Hm ..


> Date: Mon, 18 May 2015 11:14:19 +0100
> From: ma...@apache.org
> To: users@tomcat.apache.org
> Subject: Re: Tomcat valve JAAS : form error page displayed first before 
> response reaches back to Tomcat valve
> 
> On 17/05/2015 23:44, Kim Ming Yap wrote:
> > Hi,I'm building a website using form based authentication integrating with 
> > JAAS for user based authentication. I don't have issue when a successful 
> > credential is authenticated. Rather I'm having difficulty understanding the 
> > flow of JAAS back to the client should the form based authentication failed.
> > SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
> > OBJECTIVE:Custom error captured in JAAS login module to propagate to error 
> > page
> 
> You are unlikely to get much help from Tomcat with this since
> propagating back custom errors is considered poor security practise (an
> attacker should not be able to tell why authentication failed).
> 
> > BASIC UNDERSTANDING:
> > The Tomcat JAAS layer is not integrated with the web container layer. Hence 
> > the former does not have access to request, session etc.
> 
> JAAS is integrated as a Realm - i.e. something that validates
> credentials provided by an Authenticator. The Authenticator has full
> access to the request and the response. You may want to consider a
> custom Authenticator.
> 
> > SOLUTION:
> > Using ThreadLocal which capture the custom error message in JAAS layer to 
> > be used when the flow reaches back to the custom valve on the way back to 
> > the browser.
> 
> You need to be careful you don't trigger memory leaks when using
> ThreadLocals.
> 
> > PROBELM:Understanding of basic request/response flow involving Tomcat and 
> > JAAS
> > a. request --> valve --> JAAS --> Filter --> Servlet/JSPb. response <-- 
> > valve (**) <-- JAAS <-- Filter <-- Servlet/JSP
> 
> I suspect that order is wrong.
> 
> JAAS is called by the Authenticator (which is a valve). The
> Authenticator then calls the Filter (via a few other layers).
> 
> You might want to check the ordering of your valve and the Authenticator.
> 
> > (refer to above clause b)ThreadLocal in the JAAS layer managed to capture 
> > the custom error message and it i managed to print it after the getNext() 
> > method of the custom valve. Thought of adding this custom error as an 
> > attribute in the session object.
> > However I noticed that the error page is already displayed before i could 
> > add this cusom error (immediately after the getNext method).
> 
> The error page will be handled by the webapp or the ErrorReportingValve
> - both of whichh may get called before your Valve depending on how the
> Valve is configured.
> 
> > Due to that the ready custom error message cannot be used
> > SAMPLE CODES:
> > 1. web.xml
> > FORM
> >   /login.jsp  
> > /login-redirect-error.jsp?error=true
> > 
> > 2. Custom valve and defined in META-INF/context.xml
> > public class SecurityValve extends ValveBase {
> > public void invoke(Request request, Response response) throws 
> > IOException, ServletException {   getNext().invoke(request, 
> > response);   system.out.println("after getNext()"); --> break point 
> > (BP)  }
> > }
> > 1. Did a break point on SecurityValve (indicated at BP) 2. On forms, i 
> > purposely enter wrong credential and submit 3. Break point stops at 
> > BP 4. login-redirect-error.jsp displayed already5. Since it stop at 
> > break point BP in SecurityValve, the response back to client flow has not 
> > reached the browser. Yet the login-redirect-error.jsp is already displayed
> > QUESTIONS:   Ho

Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve

[Mark Thomas]

On 17/05/2015 23:44, Kim Ming Yap wrote:
> Hi,I'm building a website using form based authentication integrating with 
> JAAS for user based authentication. I don't have issue when a successful 
> credential is authenticated. Rather I'm having difficulty understanding the 
> flow of JAAS back to the client should the form based authentication failed.
> SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
> OBJECTIVE:Custom error captured in JAAS login module to propagate to error 
> page

You are unlikely to get much help from Tomcat with this since
propagating back custom errors is considered poor security practise (an
attacker should not be able to tell why authentication failed).

> BASIC UNDERSTANDING:
> The Tomcat JAAS layer is not integrated with the web container layer. Hence 
> the former does not have access to request, session etc.

JAAS is integrated as a Realm - i.e. something that validates
credentials provided by an Authenticator. The Authenticator has full
access to the request and the response. You may want to consider a
custom Authenticator.

> SOLUTION:
> Using ThreadLocal which capture the custom error message in JAAS layer to be 
> used when the flow reaches back to the custom valve on the way back to the 
> browser.

You need to be careful you don't trigger memory leaks when using
ThreadLocals.

> PROBELM:Understanding of basic request/response flow involving Tomcat and JAAS
> a. request --> valve --> JAAS --> Filter --> Servlet/JSPb. response <-- 
> valve (**) <-- JAAS <-- Filter <-- Servlet/JSP

I suspect that order is wrong.

JAAS is called by the Authenticator (which is a valve). The
Authenticator then calls the Filter (via a few other layers).

You might want to check the ordering of your valve and the Authenticator.

> (refer to above clause b)ThreadLocal in the JAAS layer managed to capture the 
> custom error message and it i managed to print it after the getNext() method 
> of the custom valve. Thought of adding this custom error as an attribute in 
> the session object.
> However I noticed that the error page is already displayed before i could add 
> this cusom error (immediately after the getNext method).

The error page will be handled by the webapp or the ErrorReportingValve
- both of whichh may get called before your Valve depending on how the
Valve is configured.

> Due to that the ready custom error message cannot be used
> SAMPLE CODES:
> 1. web.xml
> FORM  
> /login.jsp  
> /login-redirect-error.jsp?error=true
> 
> 2. Custom valve and defined in META-INF/context.xml
> public class SecurityValve extends ValveBase {
>   public void invoke(Request request, Response response) throws 
> IOException, ServletException {   getNext().invoke(request, 
> response);   system.out.println("after getNext()"); --> break point 
> (BP)  }
> }
> 1. Did a break point on SecurityValve (indicated at BP) 2. On forms, i 
> purposely enter wrong credential and submit 3. Break point stops at 
> BP 4. login-redirect-error.jsp displayed already5. Since it stop at 
> break point BP in SecurityValve, the response back to client flow has not 
> reached the browser. Yet the login-redirect-error.jsp is already displayed
> QUESTIONS:   How can the login-redirect-error.jsp be displayed on the browser 
> when the response flowing back to client stop at break point BP? The flow 
> back to the client is not fully done yet.

You are confusing control and data. The data goes back to the client as
soon as the output is flushed (which can happen in the Servlet/JSP).

> I would really appreciate any help.Thanks.

Set a break point in a JSP / Servlet and look at the stack trace to see
which Valves the request/response flow through in which order.

Mark


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

Re: Tomcat Valve Custom args

[Konstantin Kolinko]

2013/4/1 André Warnier :
> Christopher Schultz wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Karthik,
>>
>> On 4/1/13 8:28 AM, N.s.Karthik wrote:
>>>
>>> Reason : I have created a Customized valve as a separate jar  used
>>> for AAA interception of my APPS , Since I cannot configure each and
>>> every application hosted on the Tomcat with filters  and hence
>>> created a Valve to apply this at Tomcat level
>>>
>>> I use the IWA (Integrated Window Authentication)  of IE / FFOx for
>>> Active directory AAA Authentication.
>>>
>>> On-sucessfull  AAA, in the valve  I need the variables such as
>>> username/domain name  to be further  used with in each
>>> application
>>>
>>> Hence I need to know if any possibilities to fetch the variables
>>> into each of the applications from the valves ...???
>>
>>
>> Your valve can put anything you like into:
>>
>> 1. The request
>> 2. The user's session
>> 3. The application (context) scope
>>
>> I recommend #1 or #2, depending upon your needs.
>>
> Is my understanding deficient, or is #3 not true ? The Valve doesn't know
> which application has (or will be) been selected, or does it ?

1. As far as request has passed through Mapper, it knows to what
application (Context) and even to what servlet (Wrapper) it goes to.
This happens rather early - in CoyoteAdapter. It happens before the
request is passed to Pipeline (chain of valves).

org.apache.catalina.connector.Request#getContext()

2. If valve was declared in context.xml, it knows what its parent is.

>
> In the context of a Valve doing AAA - and the fact that the OP wants to get
> the authenticated user-id at the app level, I think Michael-O's answer is
> better, no ?
>

Best regards,
Konstantin Kolinko

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

Re: Tomcat Valve Custom args

[André Warnier]

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Karthik,

On 4/1/13 8:28 AM, N.s.Karthik wrote:

Reason : I have created a Customized valve as a separate jar  used
for AAA interception of my APPS , Since I cannot configure each and
every application hosted on the Tomcat with filters  and hence
created a Valve to apply this at Tomcat level

I use the IWA (Integrated Window Authentication)  of IE / FFOx for
Active directory AAA Authentication.

On-sucessfull  AAA, in the valve  I need the variables such as 
username/domain name  to be further  used with in each

application

Hence I need to know if any possibilities to fetch the variables
into each of the applications from the valves ...???


Your valve can put anything you like into:

1. The request
2. The user's session
3. The application (context) scope

I recommend #1 or #2, depending upon your needs.

Is my understanding deficient, or is #3 not true ? The Valve doesn't know which 
application has (or will be) been selected, or does it ?


In the context of a Valve doing AAA - and the fact that the OP wants to get the 
authenticated user-id at the app level, I think Michael-O's answer is better, no ?


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

Re: Tomcat Valve Custom args

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Karthik,

On 4/1/13 8:28 AM, N.s.Karthik wrote:
> Reason : I have created a Customized valve as a separate jar  used
> for AAA interception of my APPS , Since I cannot configure each and
> every application hosted on the Tomcat with filters  and hence
> created a Valve to apply this at Tomcat level
> 
> I use the IWA (Integrated Window Authentication)  of IE / FFOx for
> Active directory AAA Authentication.
> 
> On-sucessfull  AAA, in the valve  I need the variables such as 
> username/domain name  to be further  used with in each
> application
> 
> Hence I need to know if any possibilities to fetch the variables
> into each of the applications from the valves ...???

Your valve can put anything you like into:

1. The request
2. The user's session
3. The application (context) scope

I recommend #1 or #2, depending upon your needs.

- -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/

iQIcBAEBCAAGBQJRWYl7AAoJEBzwKT+lPKRYUW4QAKsbYLf2bZFiXhKn5vzkASoq
j2ggSc0jWA6fqwMgdBRmWd6ktL+4aouqfOF0aT47PuWgYOMVJZ1srMvbh4OQM6i6
8tLEJ/iE48cVqcTXw08TXKLUj5FztzG8+cQHxrFREKYu4UyrGAu7xSh6Z5cGPZCz
Q4VlwuBQ0tYOZRJoA8eIMwzR+RjMu1htmChrFxPJGv1yEPnEDnTy9lJkQ+KQ84j3
539jFH95sWOp7bPZVf0Qf1bqlUIxuf02I2VOVL/zmC91ri1fbCPwOwDXIcunz7Jd
v//GjLA5tBL2b6Qya+M5zHr34ZttyFEUcocesKHQDv+2Dq2ETrJoM4hHYis0Js+k
Mq+UU1ea9ApwaEIjNv19TMAlSV/Khj/fL5lR/dkwXjjWhF7DqzLIKyvNr2o5rozD
zNluZbJhqCpVTACPgl9E8QAdE5sk5aw6nySTcxWoLPupT1gWXLGx4WXRbl5dt2QZ
gDZltZr6+l5TT6CCqO3e0i9+YaV/j9F2pkD6nQl1uYkE94Qisoclqg4tWkUpyRGO
1ziUxsCzjoZC4zyWTDiRWaTCwrSy4IA+avyn9HqjHNav44PPx3KT5B0AHDH6OMK4
EZJ9EQbiirm8yx0l2Qom9PLdxQQHjAwqO3Y468AVwtnIknLXY12nzUa7f+ZzA6eT
WQ2bfwr1UiflQRxYeNZm
=wde5
-END PGP SIGNATURE-

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

Re: Tomcat Valve Custom args

[Michael-O]

Am 2013-04-01 14:28, schrieb N.s.Karthik:

Hi

Thx for the reply

I know that Valves are invisible to the app..

Reason :
I have created a Customized valve as a separate jar  used for AAA
interception of my APPS ,
Since I cannot configure each and every application hosted on the Tomcat
with filters  and hence created a Valve to apply this at Tomcat level

I use the IWA (Integrated Window Authentication)  of IE / FFOx for Active
directory AAA Authentication.

On-sucessfull  AAA, in the valve  I need the variables such as
username/domain name  to be further  used with in each application

Hence I need to know if any possibilities to fetch the variables  into each
of the applications from the valves ...???


I hope that you have implemented AuthenticatorBase in Tomcat with your 
custom Authenticator. With that you can register a Principal object.


I have written a fully-featured SPNEGO/AD Realm package which uses a 
custom ActiveDirectoryPrincipal extends Principal. In that I have stored 
distinguished name, objectSid, etc (source code available).


First, make the Principal#getName return either the Kerberos UPN, or if 
you use NTLM (yuck) return the legacy login name.


If your need access to further attributes do in your app:

MyCustomPrincipal principal = (MyCustomPrincipal) request.getPrincipal();

...access attributes.

That is the way to go.

Michael


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

Re: Tomcat Valve Custom args

[N.s.Karthik]

Hi

Thx for the reply

I know that Valves are invisible to the app.. 

Reason : 
I have created a Customized valve as a separate jar  used for AAA
interception of my APPS , 
Since I cannot configure each and every application hosted on the Tomcat
with filters  and hence created a Valve to apply this at Tomcat level 

I use the IWA (Integrated Window Authentication)  of IE / FFOx for Active
directory AAA Authentication.

On-sucessfull  AAA, in the valve  I need the variables such as
username/domain name  to be further  used with in each application  

Hence I need to know if any possibilities to fetch the variables  into each
of the applications from the valves ...???


with regards
Karthik  




--
View this message in context: 
http://tomcat.10.n6.nabble.com/Tomcat-Valve-Custom-args-tp4997226p4997235.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

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

Re: Tomcat Valve Custom args

[Michael-O]

Am 2013-04-01 08:25, schrieb N.s.Karthik:

Hi
  Spec:

JDK1.6
Tomcat 6.0.26
O/s nix Suse


I have build a Customized Valve and have done the required  settings in
context.xml for specific APP
and have them returned variables System.println on console ( Catalina.out)

Question :

1) How to get the return values  into a JSP file  [ using  request.  ]
of the specific APP


What variables? What is APP?

Valves are invisible to the app. There are Tomcat-only. If you need to 
set some values, resort to environment entries through JNDI. A listener 
should do that. I have asked this recently on the mailing list.



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

Re: Tomcat Valve, how to Create Pattern

[Jon Wingfield]

I may be wrong but I think there are only two predefined names: "common" 
and "combined". For all others you set the pattern attribute to the 
required number and ordering of pattern elements as defined in the docs. 
From the docs:
The shorthand pattern name common (which is also the default) 
corresponds to %h %l %u %t "%r" %s %b


So, for example, if all you wanted was the url, the time it took to 
serve and the user agent you would set the pattern to:

%U %D "%{User-Agent}i"

The latter pattern element I got from the javadoc:
http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/index.html

Jon

Scott Purcell wrote:

Tomcat 5.5
OS=Win2000

I would like to change the pattern for a valve in my server.xml. The API
shows when you have the element 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]