date:20111004


Léa Massiot wrote:
...


What's interesting is that, in the same servlets container, one WebApp has
access to another WebApp through /w1/uf1/f.txt /w2/uf2/f.txt type of
addressing.


That's only because you look at it the wrong way.
It is not that one webapp has access to another webapp, it is that the user's browser 
has (apparently) access to both webapps.
By the time one of these links gets used, it is because the html page is loaded by the 
user's browser, the user clicks on one of the links, and the browser sends a new request 
to the server.  What happens then is only a matter of the server deciding if this request, 
coming from that browser connection, is allowed to access the requested resource.
If you add an authentication requirement in one of these webapps, and not in the other, 
you will see the difference.



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

Re: Tomcat 7 jasper-el fails to parse boolean EL statement

2011-10-04 Thread Nestor Urquiza

Thank you very much!
-Nestor



On Oct 4, 2011, at 12:17 AM, Konstantin Kolinko knst.koli...@gmail.com wrote:

 2011/10/4 Nestor Urquiza nestor.urqu...@gmail.com:

 Downloading latest jasper-el
 http://repo1.maven.org/maven2/org/apache/tomcat/jasper-el/6.0.33/jasper-el-6.0.33.jar
 (from August 2011 which I consider latest - please correct me if I am
 wrong) or even copying the jar from a previous tomcat installation
 allows ${owner.new} to work. The version of jasper-el shipped with
 tomcat 7.0.22 does not. Is that a bug in jasper-el-6.0.33.jar?

 You should download ASF software from download pages on *.apache.org sites. :)

 That jar is just some random piece of Tomcat 6.0.33.  You cannot
 download it and drop into any other Tomcat version.

 It is useful if you need to compile your own code that uses those
 internal APIs of Tomcat, but you should not use it at runtime at a
 proper Tomcat instance.

 If you look into META-INF/MANIFEST.MF file inside the jar you should see that
 Specification-Title: Apache Tomcat
 Specification-Version: 6.0
 etc.

 Furthermore, the alternative ${owner.isNew()} which does work in
 Tomcat 7.0.22 default jasper-el fails when I use jasper-el-6.0.33.jar.

 ${owner['new']} is accessing property new of object owner.

 That is exactly the same that you tried with ${owner.new}.

 The ${owner.isNew()} expression is a different beast - it is a method call,

 and method calls support is introduced in JSP 2.2/Expression Language
 2.2.  You will have to use Tomcat 7.0.

 I forgot to thanks Mark for the flag.

 Thank you for taking your time and reading.


 Best regards,
 Konstantin Kolinko

 -
 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

RHEL + Tomcat6, error in logfile


Hi.

I am installing something on a customer's RedHat server.
Tomcat was obviously installed (not by me) from a RHEL package.
As far as I can tell (because I cannot find the bin/version.sh script), the Tomcat version 
is 6.0.24 (that's what various jar's seem to be named, like 
/usr/share/tomcat6/lib/catalina-6.0.24.jar).


Java version seems to be :
java version 1.6.0_26
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)
(I am not quite sure that Tomcat really uses this version, but I presume)

Anyway, I see the following messages in a catalina.(date).log file.

Any idea what this is due to ?
Should I worry about it ?
How do I get rid of it ?

message :

INFO: Stopping Coyote HTTP/1.1 on http-8080
Oct 4, 2011 4:46:25 PM org.apache.catalina.mbeans.ServerLifecycleListener 
lifecycleEvent
SEVERE: destroyMBeans: Throwable
javax.management.MalformedObjectNameException: Cannot create object name for 
org.apache.catalina.connector.Connector@3fa6cd

at 
org.apache.catalina.mbeans.MBeanUtils.createObjectName(MBeanUtils.java:764)
at 
org.apache.catalina.mbeans.MBeanUtils.destroyMBean(MBeanUtils.java:1416)
	at 
org.apache.catalina.mbeans.ServerLifecycleListener.destroyMBeans(ServerLifecycleListener.java:678)
	at 
org.apache.catalina.mbeans.ServerLifecycleListener.destroyMBeans(ServerLifecycleListener.java:1005)
	at 
org.apache.catalina.mbeans.ServerLifecycleListener.destroyMBeans(ServerLifecycleListener.java:971)
	at 
org.apache.catalina.mbeans.ServerLifecycleListener.lifecycleEvent(ServerLifecycleListener.java:154)

at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.StandardServer.stop(StandardServer.java:748)
at org.apache.catalina.startup.Catalina.stop(Catalina.java:643)
at org.apache.catalina.startup.Catalina.start(Catalina.java:618)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)

Thanks for any clues.

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

RE: RHEL + Tomcat6, error in logfile

2011-10-04 Thread Caldarale, Charles R

 From: André Warnier [mailto:a...@ice-sa.com] 
 Subject: RHEL + Tomcat6, error in logfile

 Oct 4, 2011 4:46:25 PM org.apache.catalina.mbeans.ServerLifecycleListener 
 lifecycleEvent
 SEVERE: destroyMBeans: Throwable
 javax.management.MalformedObjectNameException: Cannot create object name for 
 org.apache.catalina.connector.Connector@3fa6cd

Assuming you can find it in this non-standard environment, let's look at the 
server.xml and see if there's something odd in there, especially the 
Connector elements.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

Re: WebApps sharing uploaded files

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Léa,

On 9/30/2011 2:37 PM, Léa Massiot wrote:
 o I have two WebApps w1 and w2 (under the Tomcat webapps
 directory). o Both w1 and w2 contain (at least) a JSP which
 allows to upload files to the server. o Presently, the uploaded
 files are stored: - in the w1\uf1\ directory for w1, - in the
 w2\uf2\ directory for w2.

Be careful: if you undeploy the webapp, you will have all those files
deleted by Tomcat.

I highly recommend that you place your upload directory or
directories safely /outside/ of Tomcat's webapps directory to avoid
any possibility of Tomcat deleting those files.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6LK3cACgkQ9CaO5/Lv0PBS+gCeJyiZGOqJzB4d3lGH2puGoWAu
fhEAn3qEv8wZZT2+UcAKEZR38eXMZWtW
=Tmhq
-END PGP SIGNATURE-

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

Re: Logging properties of attributes in the HttpSession

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Konstantin,

On 10/3/2011 4:16 PM, Konstantin Kolinko wrote:
 2011/10/3 Christopher Schultz ch...@christopherschultz.net:
 On 9/30/2011 2:18 PM, Konstantin Kolinko wrote:
 2011/9/30 Christopher Schultz ch...@christopherschultz.net:
 The OP should be able to put the Filter into the Context
 in such a way that the Filter wraps the AccessLogValve, no?
 
 
 1. You cannot put a Filter into Context.
 
 Mmm. Why do I always think that you can do this sort of thing?
 Maybe I'll log an enhancement that allows us to do this: it seems
 reasonable to allow Filters to be interspersed with Valves,
 especially for things like this.
 
 This: https://issues.apache.org/bugzilla/show_bug.cgi?id=51754 
 worries me a bit more.

Allowing Valve and Filter to be arbitrarily ordered shouldn't
affect that bug, which has to do with where the default filters are
inserted into the valve/filter chain. That problem would still exist
and, IMO, not get any worse by allowing Filter to appear anywhere a
Valve can appear.

 3. A Valve can modify a Request, while Filter cannot.
 
 Both Filter and Valve can wrap the request, which can be seen as 
 modifying it, though it's not really modifying it.
 
 Valve has access to o.a.c.connector.Request object, which is
 modifiable.

Right: it is directly modifiable instead of... maskable :)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6LLFEACgkQ9CaO5/Lv0PBvsACeNB77v1spBBGq3M+q+Gm9S8RM
QRMAniS6odp+lVkhTcTMz5sYFvtET63h
=2H7h
-END PGP SIGNATURE-

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

Re: RHEL + Tomcat6, error in logfile

2011-10-04 Thread Mark Eggers

- Original Message -

 From: Caldarale, Charles R chuck.caldar...@unisys.com
 To: Tomcat Users List users@tomcat.apache.org
 Cc: 
 Sent: Tuesday, October 4, 2011 8:41 AM
 Subject: RE: RHEL + Tomcat6, error in logfile

  From: André Warnier [mailto:a...@ice-sa.com] 
  Subject: RHEL + Tomcat6, error in logfile

  Oct 4, 2011 4:46:25 PM org.apache.catalina.mbeans.ServerLifecycleListener 
 lifecycleEvent
  SEVERE: destroyMBeans: Throwable
  javax.management.MalformedObjectNameException: Cannot create object name 
 for 
  org.apache.catalina.connector.Connector@3fa6cd

 Assuming you can find it in this non-standard environment, let's look at the 
 server.xml and see if there's something odd in there, especially the 
 Connector elements.

You might try finding it like this (all from the command line):

rpm -qa | egrep ^tomcat6

rpm q package-name --filesbypkg

There should be a couple of tomcat6 packages (if RHEL is like Fedora). Provided 
they've not moved things around, that should give you a good feel concerning 
the Red Hay layout.

You should also be able to do the following to get more complete information 
about a package (including the actual Tomcat version).

yum info package-name

Hope this helps.

. . . . just my two cents.
/mde/

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

Re: Pre Compiling jsp

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Aparna,

On 10/3/2011 5:41 PM, aparna bejugam wrote:
 Can some one tell me where to put the jsp precompilation build 
 file(build.xml) in the Tomcat 7 structure.

You should not have to put your build.xml anywhere in the Tomcat 7
structure. Instead, you should point your build.xml file at the Tomcat
7 base installation and it should figure everything out.

 I have a web application called myapp which is inside webapps
 folder and has bunch of jsp files, I want to precompile them using
 the following script.
 
 project name=Webapp Precompilation default=all
 basedir=../../../
 
 property name=tomcat.home value=${basedir}/

Those basedir definitions definitely look weird to me.

 target name=jspc  taskdef classname=org.apache.jasper.JspC
 name=jasper2  

You could also do this to define all your tasks:

  import file=${catalina.home}/bin/catalina-tasks.xml /

 classpath id=jspc.classpath pathelement
 location=${java.home}/../lib/tools.jar/

You don't need tools.jar anymore. This must be really old.

 jasper2 validateXml=false uriroot=${webapp.path} 
 webxml=${outputdir}/WEB-INF/web.xml 
 webXmlFragment=${webapp.path}/WEB-INF/generated_web.xml 
 outputDir=${outputdir}/WEB-INF/src /jasper2

Okay, does that work? Specifying webxml and webXMLFragment probably
isn't necessary.

 java classname=org.apache.jasper.JspC fork=true 
 dir=${outputdir}/WEB-INF/src

Invoking JspC again? That's just Jasper all over again. At this point,
all you need to do it compile the generated .java files using javac.

 Right now I have this build file called build.xml inside the build
 folder in myapp. So final structure is myapp has bunch of jsp files
 and a build folder with build.xml to precompile the jsps. When I
 run the above build.xml using ant I get the following error.
 
 
 BUILD FAILED 
 C:\apache-tomcat-7.0.16\webapps\myapp\build\build.xml:29:

You should upgrade to 7.0.22 if you can possibly do it.

I've been working on a build-jspc.xml ant script that should take care
of a number of these tasks for you. Here it is in it's current form.
No promises. Put the following file into catalina.home/build-jspc.xml:

?xml version=1.0 encoding=UTF-8 ?
!--
 Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the License); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an AS IS BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
- --
project name=Tomcat-JSPC default= basedir=.
  import file=${catalina.home}/bin/catalina-tasks.xml /

  target name=jspc description=Compiles JSPs
depends=jspc:jasper, jspc:javac, jspc:jar
  /target

  target name=jspc:jasper
condition property=jspc-configuration-okay
  and
isset property=catalina.home /
isset property=jspc.target.dir /
isset property=jspc.source.dir /
resourcecount refid=compile.classpath when=greater
count=0 /
  /and
/condition

fail unless=jspc-configuration-okay
  JspC requires the following properties to be set:

  catalina.home=${catalina.home}
  jspc.target.dir=${jspc.target.dir}
  jspc.source.dir=${jspc.source.dir}

  Also, you need to have the following classpath reference set:
  lt;path id=jspc.classpathgt;

  It should point to all of the classes and libraries referenced
  by your JSP sources.
/fail

delete dir=${jspc.target.dir} /
mkdir dir=${jspc.target.dir} /
mkdir dir=${jspc.target.dir}/src /
mkdir dir=${jspc.target.dir}/classes /
mkdir dir=${jspc.target.dir}/META-INF /

!-- Define Jasper task with preferred classpath --
taskdef classname=org.apache.jasper.JspC name=jasper
  classpath
path refid=jspc.classpath /
fileset dir=${catalina.home}/bin includes=*.jar /
fileset dir=${catalina.home}/lib includes=*.jar /
  /classpath
/taskdef

!-- Invoke Jasper --
jasper compile=false
uriroot=${jspc.source.dir}
outputDir=${jspc.target.dir}/src
webXmlFragment=${jspc.target.dir}/META-INF/web-fragment.xml
/jasper
  /target

  target name=jspc:javac
!-- Compile the classes --
javac srcdir=${jspc.target.dir}/src
   destdir=${jspc.target.dir}/classes
   deprecation=${javac.deprecation}
   includeAntRuntime=false
  classpath
path refid=jspc.classpath /
fileset dir=${catalina.home}/lib includes=*.jar /

Using multiple login pages

Hello

I have a realm defined as follows in my application's web.xml file:

login-config
   auth-methodFORM/auth-method
   realm-nameForm-Based Authentication Area/realm-name
   form-login-config
   form-login-page/jsp/security/protected/login.jsp/form-login-page
   form-error-page/jsp/security/protected/error.jsp/form-error-page
   /form-login-config
/login-config

Which means that all users must log in from the page ...login.jsp.

But is it possible with Tomcat 6.0.26 for multiple login pages to be specified? 
And could this be 
combined with specifying several welcome pages depending upon which login page 
I use? 

For example:

loginPageA.jsp calls index.jsp
loginPageB.jsp calls doThis.jsp
loginPageC.jsp calls doThat.jsp

Thanks

Martin O'Shea.
-- 


-
Visit Pipex Business: The homepage for UK Small Businesses

Go to http://www.pipex.co.uk/business-services


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

RE: Using multiple login pages

2011-10-04 Thread Caldarale, Charles R

 From: app...@dsl.pipex.com [mailto:app...@dsl.pipex.com] 
 Subject: Using multiple login pages 

 is it possible with Tomcat 6.0.26 for multiple login pages 
 to be specified?

Read the servlet spec, especially section 13.2.  A webapp may have only one 
login-config element, so there cannot be multiple login pages, if you stick 
with declarative security.  Various frameworks (e.g., Spring) _might_ have the 
ability to display different login pages in a single webapp, but you'll have to 
look at the doc for those.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

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

RE: Using multiple login pages

Before I look at the specification, maybe I should clarify my question: can I 
have the login form 
embedded in different pages? This way, there would be only one login-config 
element where re-
direction could resolve the welcome page issue once login is achieved.

Each page would then be able to direct  each of which calls the same login 
authentication, but 

Quoting Caldarale, Charles R chuck.caldar...@unisys.com:

  From: app...@dsl.pipex.com [mailto:app...@dsl.pipex.com] 
  Subject: Using multiple login pages 
 
  is it possible with Tomcat 6.0.26 for multiple login pages 
  to be specified?
 
 Read the servlet spec, especially section 13.2.  A webapp may have only one
 login-config element, so there cannot be multiple login pages, if you stick
 with declarative security.  Various frameworks (e.g., Spring) _might_ have
 the ability to display different login pages in a single webapp, but you'll
 have to look at the doc for those.
 
  - Chuck
 
 
 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
 MATERIAL and is thus for use only by the intended recipient. If you received
 this in error, please contact the sender and delete the e-mail and its
 attachments from all computers.
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 


-- 


-
Visit Pipex Business: The homepage for UK Small Businesses

Go to http://www.pipex.co.uk/business-services


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

problem with session replication in tomcat 5.5.23

2011-10-04 Thread Gabriele Faelli

Hi all,
I'm running tomcat 5.5.23 on two RHEL 5.6.
I'm having big trouble making the session replication working across these
two nodes.
I configured a cluster and it looks like working: each node discovers the
other one, I can see in the logs every received and transmitted ping.
Well, when I create a session in the logs there are no mention of sessions
being replicated and/or errors encounter while trying.
The applications running on tomcat have the distributable/ entry in their
web.xml and this is the cluster config part of the server.xml:

Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster
defaultMode=true

managerClassName=org.apache.catalina.cluster.session.DeltaManager
manager.expireSessionsOnShutdown=false
manager.useDirtyFlag=false
manager.notifyListenersOnReplication=true
manager.notifySessionListenersOnReplication=true
manager.sendAllSessions=true
Membership
className=org.apache.catalina.cluster.mcast.McastService
mcastAddr=228.0.0.4
mcastPort=45564
mcastFrequency=500
mcastDropTime=3000/
Receiver
className=org.apache.catalina.cluster.tcp.ReplicationListener
tcpListenAddress=192.168.199.101
tcpListenPort=4001
tcpSelectorTimeout=100
tcpThreadCount=6/
Sender
className=org.apache.catalina.cluster.tcp.ReplicationTransmitter
replicationMode=synchronous
ackTimeout=15000
waitForAck=true
autoConnect=true/
Valve
className=org.apache.catalina.cluster.tcp.ReplicationValve

filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/
Deployer
className=org.apache.catalina.cluster.deploy.FarmWarDeployer
tempDir=/tmp/war-temp/
deployDir=/tmp/war-deploy/
watchDir=/tmp/war-listen/
watchEnabled=false/

ClusterListener
className=org.apache.catalina.cluster.session.ClusterSessionListener/
/Cluster

Any Idea? Where I'm wrong? I did something stupid for sure :)
I tried every configuration, suggest... well everything I found on the
official an unofficial documentation... I'm quite frustated :P
Thanks in advance
G.

Re: RHEL + Tomcat6, error in logfile

Caldarale, Charles R wrote:
From: André Warnier [mailto:a...@ice-sa.com] 
Subject: RHEL + Tomcat6, error in logfile

Oct 4, 2011 4:46:25 PM org.apache.catalina.mbeans.ServerLifecycleListener 
lifecycleEvent
SEVERE: destroyMBeans: Throwable
javax.management.MalformedObjectNameException: Cannot create object name for 
org.apache.catalina.connector.Connector@3fa6cd

Assuming you can find it in this non-standard environment, let's look at the 
server.xml and see if there's something odd in there, especially the 
Connector elements.

Yes ! I found it ! in /etc/tomcat6 of all places.
Anyway, with comments removed, here is what it contains.

Note that I have left in the commented-out HTTPS connector, because I find it strange that 
two other connectors reference its port, but that it is itself commented out.
I don't know if it matters, but I imagine that removing the redirectPort attributes in 
the HTTP and AJP Connectors would not hurt, would it ?

Anyway, I don't see anything strange here, do you ?

server.xml :

?xml version='1.0' encoding='utf-8'?
Server port=8005 shutdown=SHUTDOWN

  GlobalNamingResources
Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
  description=User database that can be updated and saved
  factory=org.apache.catalina.users.MemoryUserDatabaseFactory
  pathname=conf/tomcat-users.xml /
  /GlobalNamingResources
  Service name=Catalina
Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 /

   !--
Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true
   maxThreads=150 scheme=https secure=true
   clientAuth=false sslProtocol=TLS /
--

!-- Define an AJP 1.3 Connector on port 8009 --
Connector port=8009 protocol=AJP/1.3 redirectPort=8443 /

Engine name=Catalina defaultHost=localhost
  Realm className=org.apache.catalina.realm.UserDatabaseRealm
 resourceName=UserDatabase/
  Host name=localhost  appBase=webapps
unpackWARs=true autoDeploy=true
xmlValidation=false xmlNamespaceAware=false
  /Host
/Engine
  /Service
/Server

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

Re: WebApps sharing uploaded files


Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Léa,

On 9/30/2011 2:37 PM, Léa Massiot wrote:

o I have two WebApps w1 and w2 (under the Tomcat webapps
directory). o Both w1 and w2 contain (at least) a JSP which
allows to upload files to the server. o Presently, the uploaded
files are stored: - in the w1\uf1\ directory for w1, - in the
w2\uf2\ directory for w2.


Be careful: if you undeploy the webapp, you will have all those files
deleted by Tomcat.

I highly recommend that you place your upload directory or
directories safely /outside/ of Tomcat's webapps directory to avoid
any possibility of Tomcat deleting those files.


Right. But then, Lea's simple scheme for download will stop working.
Damn..

Or, wasn't there a possibility to place a symlink within the webapps dir, and have Tomcat 
/not/ following it when undeploying ? Or was that precisely the catch, that it always does ?


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

Re: Denying IPs using the Valve command in context.xml

2011-10-04 Thread Konstantin Kolinko

2011/10/4 Sanford Stein sanford.st...@cybertools.biz

 1.  I am using wildcards in my IP addresses, such as:
 Valve className=org.apache.catalina.valves.RemoteAddrValve 
 deny=*.googlebot.com/

 From my reading of the documentation, this should be OK, but when this line 
 is present I cannot access any of my
 servlets from any IP address.   Do wildcards work here and, if so, what am I 
 doing wrong?

1. Please do not send HTML e-mails to this mailing list.
2. Your exact Tomcat version = ?
3. Wildcards never worked there. RemoteAddrValve uses Regular expressions.
4. RemoteAddrValve  works with IP addresses, not host names.

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

Re: WebApps sharing uploaded files

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 10/4/2011 1:31 PM, André Warnier wrote:
 Or, wasn't there a possibility to place a symlink within the
 webapps dir, and have Tomcat /not/ following it when undeploying ?
 Or was that precisely the catch, that it always does ?

Look for aliases:
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6LRTgACgkQ9CaO5/Lv0PCTYQCgjwa6es45TZpcKXDdJAF7ZJcx
ldgAnRUp90hvnuk3J9zJQ9sg8GK0vmWD
=k2fm
-END PGP SIGNATURE-

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

Re: Denying IPs using the Valve command in context.xml

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sanford,

On 10/4/2011 1:21 PM, Sanford Stein wrote:
 1.  I am using wildcards in my IP addresses, such as: Valve
 className=org.apache.catalina.valves.RemoteAddrValve 
 deny=*.googlebot.com/

That doesn't look like a valid regular expression.

 From my reading of the documentation, this should be OK, but when
 this line is present I cannot access any of my servlets from any IP
 address.   Do wildcards work here and, if so, what am I doing
 wrong?

You are trying to use a glob-style wildcard instead of a regular
expression.

 2.  Is it possible for a give IP to permit access to some servlets
 while denying access to others?

I don't think you can do this with a Valve, but you can do it with a
Filter
(http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Remote_Address_Filter)
that is only mapped to certain servlets.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6LRdwACgkQ9CaO5/Lv0PDUvwCfaycwYGMvZc7l7qGf618uIUa9
DKwAn3gcfFCmsYA+GO9K2FFxchMZUUq3
=5fnP
-END PGP SIGNATURE-

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

Re: Using multiple login pages

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin,

On 10/4/2011 1:12 PM, app...@dsl.pipex.com wrote:
 Before I look at the specification

:(

You should read the spec all the way through IMO. It's not that long,
it's well-written and readable by real humans (and not
techno-lawyers), and very informative.

 maybe I should clarify my question: can I have the login form 
 embedded in different pages?

You can put your login form wherever you want. Just be aware that the
container is going to intercept any non-authenticated access attempts
to protected resources and forward them to the one-and-only login page
you have configured in form-login-page.

 This way, there would be only one login-config element where re- 
 direction could resolve the welcome page issue once login is
 achieved.
 
 Each page would then be able to direct  each of which calls the
 same login authentication, but

But what?

Your login.jsp page can forward/include anything it wants, as long as
none of the resources it tries to include/forward to are protected.

So, you can sniff the original request URI and serve-up whatever
flavor of login page you want. To see how to do *that*, I'm going to
make you read the spec :)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6LRtoACgkQ9CaO5/Lv0PDdiACgiXTpEM7sH9ttfSzyf2n4e+0v
XsEAmwWgoS08TAcSwMzN5hI8ox+7SnDZ
=Ihdu
-END PGP SIGNATURE-

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

Re: Denying IPs using the Valve command in context.xml

Here are the Valves which exist under Tomcat 7.0, the latest version.
http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html
Which one are you talking about, and which Tomcat version ?

Note that org.apache.catalina.valves.RemoteAddrValve can filter on the base of the client
/IP address/, not its hostname (as a careful read of the on-line documentation makes clear).

Note also that as well the org.apache.catalina.valves.RemoteHostValve as the
org.apache.catalina.valves.RemoteAddrValve filter on the base of /regular expressions/,
and *.googlebot.com is not one of those.

In this particular case, \.googlebot\.com$ would be better (with the
RemoteHostValve).

And finally, note also that this may be quite expensive, in the sense that Tomcat may
need to do a couple of DNS lookups per client, to allow this to work.
In this particular case, would a robots.txt file in the ROOT of your server, not be
better ? Google bots should be well-behaved.

Sanford Stein wrote:

1. I am using wildcards in my IP addresses, such as:
Valve className=org.apache.catalina.valves.RemoteAddrValve
deny=*.googlebot.com/

From my reading of the documentation, this should be OK, but when this line is
present I cannot access any of my
servlets from any IP address. Do wildcards work here and, if so, what am I
doing wrong?

2. Is it possible for a give IP to permit access to some servlets while denying
access to others?

Thanks,
Sanford Stein
CyberTools Inc.
--

CyberTools Logo http://CyberTools.biz *Sanford Stein *| *CyberTools, Inc.*
75 Arlington Street, Suite 500, Boston MA 02116 | 800.894.9206 x 103 | F
888.899.0346
sanford.st...@cybertools.biz mailto:sanford.st...@cybertools.biz |
CyberTools.biz http://CyberTools.biz | Build-It-Once Development

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

Re: Using multiple login pages

Thanks Chris. I'll be reading the spec soon enough.

Quoting Christopher Schultz ch...@christopherschultz.net:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Martin,
 
 On 10/4/2011 1:12 PM, app...@dsl.pipex.com wrote:
  Before I look at the specification
 
 :(
 
 You should read the spec all the way through IMO. It's not that long,
 it's well-written and readable by real humans (and not
 techno-lawyers), and very informative.
 
  maybe I should clarify my question: can I have the login form 
  embedded in different pages?
 
 You can put your login form wherever you want. Just be aware that the
 container is going to intercept any non-authenticated access attempts
 to protected resources and forward them to the one-and-only login page
 you have configured in form-login-page.
 
  This way, there would be only one login-config element where re- 
  direction could resolve the welcome page issue once login is
  achieved.
  
  Each page would then be able to direct  each of which calls the
  same login authentication, but
 
 But what?
 
 Your login.jsp page can forward/include anything it wants, as long as
 none of the resources it tries to include/forward to are protected.
 
 So, you can sniff the original request URI and serve-up whatever
 flavor of login page you want. To see how to do *that*, I'm going to
 make you read the spec :)
 
 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAk6LRtoACgkQ9CaO5/Lv0PDdiACgiXTpEM7sH9ttfSzyf2n4e+0v
 XsEAmwWgoS08TAcSwMzN5hI8ox+7SnDZ
 =Ihdu
 -END PGP SIGNATURE-
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 


-- 


-
Visit Pipex Business: The homepage for UK Small Businesses

Go to http://www.pipex.co.uk/business-services


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

Re: WebApps sharing uploaded files


Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 10/4/2011 1:31 PM, André Warnier wrote:

Or, wasn't there a possibility to place a symlink within the
webapps dir, and have Tomcat /not/ following it when undeploying ?
Or was that precisely the catch, that it always does ?


Look for aliases:
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html


Thanks. Seen.  Lea, do you follow ?

By the way, in that same page, the next item is :

quote

allowLinking

If the value of this flag is true, symlinks will be allowed inside the web application, 
pointing to resources outside the web application base path. If not specified, the default 
value of the flag is false.


NOTE: This flag MUST NOT be set to true on the Windows platform (or any other OS which 
does not have a case sensitive filesystem), as it will disable case sensitivity checks, 
allowing JSP source code disclosure, among other security problems.


unquote

Is this second paragraph really well-placed there ?
Does allowLinking really influence case-sensitivity ?


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

Re: Using multiple login pages


Christopher Schultz wrote:
...

(I agree with what precedes this)


So, you can sniff the original request URI and serve-up whatever
flavor of login page you want. 


But with declarative security, that's kind of hard to do, no ?
Can't do that with a Servlet Filter.


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

Re: Using multiple login pages

Not sure about which version of security I will use but I would like to 
accommodate MD5 
verification into things. There's no sensitive or confidential info in the 
system either so 
protected page access may not be required. 

Thanks Andre and Chris.

Quoting AndrÃ© Warnier a...@ice-sa.com:

 Christopher Schultz wrote:
 ...
 
 (I agree with what precedes this)
  
  So, you can sniff the original request URI and serve-up whatever
  flavor of login page you want. 
 
 But with declarative security, that's kind of hard to do, no ?
 Can't do that with a Servlet Filter.
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 


-- 


-
Visit Pipex Business: The homepage for UK Small Businesses

Go to http://www.pipex.co.uk/business-services


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

Re: Denying IPs using the Valve command in context.xml

On Tue, Oct 4, 2011 at 19:49, André Warnier a...@ice-sa.com wrote:
[...]

 In this particular case, \.googlebot\.com$ would be better (with the
 RemoteHostValve).


No, that would not even work, for there is a fatal flaw in all
existing Valves and Filters using regexes: they use the .matches()
method of Matcher instead of .lookingAt(), which means you _must_
specify the whole hostname in the regex...

-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
f...@one2team.com
40 avenue Raymond Poincaré
75116 Paris

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

Re: Request for comments: Apache-like allow/deny remote host filtering

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Francis,

On 10/2/2011 3:57 PM, Francis GALIEGUE wrote:
 On Sun, Oct 2, 2011 at 19:46, Konstantin Kolinko 
 knst.koli...@gmail.com wrote:
 2011/10/2 Francis GALIEGUE f...@one2team.com:
 
 
 1. If you want to submit it as a patch for Tomcat, you should 
 attach it to a Bugzilla issue.
 
 OK, will do.

+1

Is there a way to see the code as a diff instead of complete files?
This looks like a diff where the whole file is new.

 4. In Tomcat 7 there are  RemoteAddrValve and RemoteAddrFilter. 
 Both implement the same filtering, but one is implemented as a 
 valve, another as a filter.
 
 I hadn't seen that. Thanks for the correction!

It appears that no changes would be needed to either the Filter or the
Valve -- only to the shared implementation that interprets the meaning
of those settings.

 5. Tomcat 7 has tests written for JUnit. I'd be nice if your 
 valve had such tests. To start testsuite you execute the test 
 target in Tomcat's build.xml.
 
 You can run a single test by setting test.entry property in 
 build.properties equal to the test name. Otherwise the full 
 testsuite will be run.
 
 
 That's in the plan.

I don't see jmock in the set of libs available for TC7, so you may
have to play some games with HttpServletRequestWrapper in order to
test this thing properly.

Let us know if you need any help.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6LU8sACgkQ9CaO5/Lv0PAdXQCeKgIMXbD+jvtrRcnLHQFH1JDZ
gQ8AoMIbwvUrPv936WCIYm69zAdoMXVD
=YiPA
-END PGP SIGNATURE-

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

Re: Denying IPs using the Valve command in context.xml

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Francis,

On 10/4/2011 2:37 PM, Francis GALIEGUE wrote:
 On Tue, Oct 4, 2011 at 19:49, André Warnier a...@ice-sa.com wrote: 
 [...]
 
 In this particular case, \.googlebot\.com$ would be better
 (with the RemoteHostValve).
 
 
 No, that would not even work, for there is a fatal flaw in all 
 existing Valves and Filters using regexes: they use the .matches() 
 method of Matcher instead of .lookingAt(), which means you _must_ 
 specify the whole hostname in the regex...

Are you saying that .*\.googlebot\.com doesn't work?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6LVIQACgkQ9CaO5/Lv0PDxPQCdHaH4ecRo0h/TXmdRYMZ1Egx2
ZfUAoIjk3/F2inEAM4eFxEcR6NXA5kva
=Xmb9
-END PGP SIGNATURE-

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

Re: Using multiple login pages

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 10/4/2011 2:01 PM, André Warnier wrote:
 Christopher Schultz wrote: ...
 
 (I agree with what precedes this)
 
 So, you can sniff the original request URI and serve-up whatever 
 flavor of login page you want.
 
 But with declarative security, that's kind of hard to do, no ? 
 Can't do that with a Servlet Filter.

Something like this:

form-login-page/login.jsp/form-login-page

login.jsp:

%
  if(original_uri.equals(/one_thing))
  {
dispatcher.include(/login_form_A.jsp);
  }
  else if(original_uri.equals(/another_thing))
  {
dispatcher.include(/login_form_B.jsp);
  }
  else
  {
   dispatcher.include(/login_form_default.jsp);
  }
%

That's not terribly difficult to do. You can use whatever logic you want.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6LVRAACgkQ9CaO5/Lv0PCn6QCgl/ncRiyICo1reGjEi7kK9x+S
xh4AoIdC5yS+fX6AnbUP3Z4sn5N81yLU
=jvTt
-END PGP SIGNATURE-

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

Re: Request for comments: Apache-like allow/deny remote host filtering

On Tue, Oct 4, 2011 at 20:43, Christopher Schultz
ch...@christopherschultz.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Francis,

 On 10/2/2011 3:57 PM, Francis GALIEGUE wrote:
 On Sun, Oct 2, 2011 at 19:46, Konstantin Kolinko
 knst.koli...@gmail.com wrote:
 2011/10/2 Francis GALIEGUE f...@one2team.com:


 1. If you want to submit it as a patch for Tomcat, you should
 attach it to a Bugzilla issue.

 OK, will do.

 +1

 Is there a way to see the code as a diff instead of complete files?
 This looks like a diff where the whole file is new.


Indeed. Patch attached. I didn't know Bugzilla would treat patches this way...

[...]

 It appears that no changes would be needed to either the Filter or the
 Valve -- only to the shared implementation that interprets the meaning
 of those settings.


I implemented those two interfaces again, since the existing abstract
class wouldn't fit the bill (it only tried regexes). Or maybe I don't
understand what you actually mean?

[...]

 You can run a single test by setting test.entry property in
 build.properties equal to the test name. Otherwise the full
 testsuite will be run.


 That's in the plan.

 I don't see jmock in the set of libs available for TC7, so you may
 have to play some games with HttpServletRequestWrapper in order to
 test this thing properly.

 Let us know if you need any help.


Well, I need help precisely on the above... I have a hard time
figuring out how TestRemoteIP{Filter,Valve} work at all... But I've
been only having a superficial glance at them so far.

Have fun!
-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
f...@one2team.com
40 avenue Raymond Poincaré
75116 Paris

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

Re: Denying IPs using the Valve command in context.xml

On Tue, Oct 4, 2011 at 20:46, Christopher Schultz
ch...@christopherschultz.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Francis,

 On 10/4/2011 2:37 PM, Francis GALIEGUE wrote:
 On Tue, Oct 4, 2011 at 19:49, André Warnier a...@ice-sa.com wrote:
 [...]

 In this particular case, \.googlebot\.com$ would be better
 (with the RemoteHostValve).


 No, that would not even work, for there is a fatal flaw in all
 existing Valves and Filters using regexes: they use the .matches()
 method of Matcher instead of .lookingAt(), which means you _must_
 specify the whole hostname in the regex...

 Are you saying that .*\.googlebot\.com doesn't work?


No, this would work. However, \.googlebot\.com$ will not.

-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
f...@one2team.com
40 avenue Raymond Poincaré
75116 Paris

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

Re: Using multiple login pages

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin,

On 10/4/2011 2:06 PM, app...@dsl.pipex.com wrote:
 Not sure about which version of security I will use but I would
 like to accommodate MD5 verification into things.

Note that MD5 doesn't verify anything. It's just a hashing function that
can be used to fingerprint data. I highly recommend:

a. Switching to another hash function if you can: MD5 kind of sucks
b. Limit the amount of data that can be hashed by some reasonable amount
   (we use a 4096-character limit on passwords)
c. Salt your hashes in case someone steals your password database
   (Tomcat's realms are not sufficient for this: you'll have to build
your own)

Tomcat's realms are all capable of hashing credentials based upon any
available hashing algorithm to the JVM.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6LVlAACgkQ9CaO5/Lv0PBLsgCeMfQ1lCblNw0lJwHnaK+FnmUK
zHEAn07N25ffZv5kwr679pk+zcIh6fOz
=/oVk
-END PGP SIGNATURE-

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

Re: Using multiple login pages

app...@dsl.pipex.com wrote:
Not sure about which version of security I will use but I would like to accommodate MD5
verification into things. There's no sensitive or confidential info in the system either so
protected page access may not be required.

I don't know what you have in mind, but there are some basic principles to
avoid wasting
your time :

1) In Tomcat (and other servlet engines), there are 2 different ways of doing
authentication :
- declarative, as per web.xml. In that case Tomcat, /before it evens calls the
webapp or
any filter in it/, intercepts a non-authenticated call and returns *the* login
form to the
browser. It then (later) intercepts the submit of that form by the browser,
checks the
credentials, and if they pass muster, it allows the call to proceed to the
webapp which
the user wanted in the first place.
- application- or filter-based authentication : in this case, Tomcat is not
aware that
there is an authentication taking place. It forwards the call to the webapp,
and a filter
/in the webapp/ intercepts the call and does whatever is needed to check the
authentication, return a login form etc..
This second authentication scheme is probably more flexible for doing the kind
of thing
you seem to want to do (but also more complex to do).

2) There already exist a number of authentication systems on the market. Unless this is
considered as an exercise, re-use an existing one instead of rolling you own. Web
authentication looks deceptively simple, but is in fact quite complex and delicate, and
open to many mistakes which completely defeat the purpose.

(This being said, if it is an exercise, it is an interesting area).

3) anything that your server sends to a browser should be considered open and
lost.
Once you send something out there, the recipient can do with it what
he wants : save it, analyse it, copy it, decompile it, falsify it, re-send it
to your
server and whatnot. There is no practical way to avoid that.
(You don't even know that it is really a browser out there).

4) the only good way to secure things if you do form authentication, is to work
over HTTPS.
The customer is going to type a login-id and a password, in the form, in clear.
The browser is going to send this over HTTP to the server.
Anyone who can sniff this traffic is going to see what is sent.
And even if he does not understand it, he can record it and replay it.
But not under HTTPS.

5) users always take the easy path. That means that, if they can choose their
password,
they will pick the same one as the one they use already for their network login, for their
email account, for their bank account, etc.. So if anyone subverts /your/ login system -
even if on /your/ server there is nothing vital to grab - the damage is probably not
limited to your server. You don't want to be accused of facilitating the bad guy's job.

6) If you are thinking of encrypting the data in the browser, it's probably not
worth the
effort. For that, you will have to write some special code, and download it to
the
browser to run it there. Once you do that, it can be saved, analysed, replicated,
falsified, disabled.

So why bother ?

HTH. Been there, etc..

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

Re: Request for comments: Apache-like allow/deny remote host filtering

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Francis,

On 10/4/2011 2:50 PM, Francis GALIEGUE wrote:
 Patch attached. I didn't know Bugzilla would treat patches this
 way...

Can you give us a link to the bug?

 I implemented those two interfaces again, since the existing
 abstract class wouldn't fit the bill (it only tried regexes). Or
 maybe I don't understand what you actually mean?

I'll have to look at the base classes... I seem to recall a great deal
of extending and overriding in that package.

 Well, I need help precisely on the above... I have a hard time 
 figuring out how TestRemoteIP{Filter,Valve} work at all... But
 I've been only having a superficial glance at them so far.

The good thing is that you only have to do a very simple test harness.
Something like this:

FilterConfig config = .. // mock-up the filter config
FilterChain chain = .. // mock-up the filter chain
Filter filter = new RemoteAddrFilter();
filter.init(config);

HttpServletRequest request = ... // mock-up request
HttpServletResponse response = ... // mock-up response

foreach(ip in test_ips) {
  // request.setRemoteAddr(ip);
  filter.doFilter(request, response, chain);

  assertEquals(expected_status_code, response.getStatusCode());
}

Of course, you'll have to do some significant work to make sure that
the filter chain is mocked-up correctly and that your request object
can be programmed appropriately.

Perhaps that's what you were hoping to get some help doing? :)

If so, I'll keep going.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6LWEgACgkQ9CaO5/Lv0PCtLQCbBH+EHvUg6GwhgcL+RefS6f11
qPoAmwRZq7YY352W77bnpndfHdl4CyG4
=vTv7
-END PGP SIGNATURE-

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

Re: WebApps sharing uploaded files

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 10/4/2011 1:56 PM, André Warnier wrote:
 quote
 
 allowLinking
 
 If the value of this flag is true, symlinks will be allowed inside
 the web application, pointing to resources outside the web
 application base path. If not specified, the default value of the
 flag is false.
 
 NOTE: This flag MUST NOT be set to true on the Windows platform (or
 any other OS which does not have a case sensitive filesystem), as
 it will disable case sensitivity checks, allowing JSP source code
 disclosure, among other security problems.
 
 unquote
 
 Is this second paragraph really well-placed there ? Does
 allowLinking really influence case-sensitivity ?

I'm not sure. I think, on Windows, links (like My Link.lnk) need to
be processed separately, and, of course, case cannot be considered
significant on FAT and NTFS. There are other kinds of symlinks (not
My Link.lnk) available on NTFS, but I'm not sure of their semantics.

Also note that allowLinking can cause problems with Tomcat's
slash-and-burn policy when undeploying webapps on *NIX (and possibly
on Windows as well).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6LWRAACgkQ9CaO5/Lv0PDJuwCfeZaBGYgxrrZ4cn4RHiJIspUW
sqQAnjX5JykypI8V11aR1CmhDp2Fern2
=xaSN
-END PGP SIGNATURE-

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

Re: WebApps sharing uploaded files

2011-10-04 Thread markt

André Warnier a...@ice-sa.com wrote:

Christopher Schultz wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 André,
 
 On 10/4/2011 1:31 PM, André Warnier wrote:
 Or, wasn't there a possibility to place a symlink within the
 webapps dir, and have Tomcat /not/ following it when undeploying ?
 Or was that precisely the catch, that it always does ?
 
 Look for aliases:
 http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
 
Thanks. Seen.  Lea, do you follow ?

By the way, in that same page, the next item is :

quote

allowLinking   

If the value of this flag is true, symlinks will be allowed inside the
web application, 
pointing to resources outside the web application base path. If not
specified, the default 
value of the flag is false.

NOTE: This flag MUST NOT be set to true on the Windows platform (or any
other OS which 
does not have a case sensitive filesystem), as it will disable case
sensitivity checks, 
allowing JSP source code disclosure, among other security problems.

unquote

Is this second paragraph really well-placed there ?

Yes.

Does allowLinking really influence case-sensitivity ?

Yes.

Mark





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

Re: Denying IPs using the Valve command in context.xml

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Francis,

On 10/4/2011 2:53 PM, Francis GALIEGUE wrote:
 On Tue, Oct 4, 2011 at 20:46, Christopher Schultz 
 ch...@christopherschultz.net wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 Francis,
 
 On 10/4/2011 2:37 PM, Francis GALIEGUE wrote:
 On Tue, Oct 4, 2011 at 19:49, André Warnier a...@ice-sa.com
 wrote: [...]
 
 In this particular case, \.googlebot\.com$ would be better 
 (with the RemoteHostValve).
 
 
 No, that would not even work, for there is a fatal flaw in all 
 existing Valves and Filters using regexes: they use the
 .matches() method of Matcher instead of .lookingAt(), which
 means you _must_ specify the whole hostname in the regex...
 
 Are you saying that .*\.googlebot\.com doesn't work?
 
 
 No, this would work. However, \.googlebot\.com$ will not.

- From the docs:

If this attribute [allow] is specified, the remote address MUST match
for this request to be accepted.

If this attribute [deny] is specified, the remote address MUST NOT
match for this request to be accepted.

I don't think Matacher.lookingAt is appropriate for this kind of checking.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6LWcgACgkQ9CaO5/Lv0PC8xACgqAzmTNKrfbmpDZAkFK4RgjfV
C8gAn0f0bZB10jP6O1wjfJSl9tTYTBuK
=ejl6
-END PGP SIGNATURE-

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

Re: Request for comments: Apache-like allow/deny remote host filtering

On Tue, Oct 4, 2011 at 21:02, Christopher Schultz
ch...@christopherschultz.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Francis,

 On 10/4/2011 2:50 PM, Francis GALIEGUE wrote:
 Patch attached. I didn't know Bugzilla would treat patches this
 way...

 Can you give us a link to the bug?


https://issues.apache.org/bugzilla/show_bug.cgi?id=51953

[...]

 The good thing is that you only have to do a very simple test harness.
 Something like this:

 FilterConfig config = .. // mock-up the filter config
 FilterChain chain = .. // mock-up the filter chain
 Filter filter = new RemoteAddrFilter();
 filter.init(config);

 HttpServletRequest request = ... // mock-up request
 HttpServletResponse response = ... // mock-up response

 foreach(ip in test_ips) {
  // request.setRemoteAddr(ip);
  filter.doFilter(request, response, chain);

  assertEquals(expected_status_code, response.getStatusCode());
 }

 Of course, you'll have to do some significant work to make sure that
 the filter chain is mocked-up correctly and that your request object
 can be programmed appropriately.

 Perhaps that's what you were hoping to get some help doing? :)


Indeed. Not right now though, I want to read some more first ;)


Thanks,
-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
f...@one2team.com
40 avenue Raymond Poincaré
75116 Paris

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

Re: Denying IPs using the Valve command in context.xml

On Tue, Oct 4, 2011 at 21:08, Christopher Schultz
ch...@christopherschultz.net wrote:
[...]

 - From the docs:

 If this attribute [allow] is specified, the remote address MUST match
 for this request to be accepted.

 If this attribute [deny] is specified, the remote address MUST NOT
 match for this request to be accepted.

 I don't think Matacher.lookingAt is appropriate for this kind of checking.


Well, it depends on the definition of match, I guess. For me, a
regex matches an input if it matches anywhere in the input! Which is
pretty much the definition of regex matching, and which is why Java's
.matches() methods are misnomers...

-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
f...@one2team.com
40 avenue Raymond Poincaré
75116 Paris

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

Re: Denying IPs using the Valve command in context.xml

2011-10-04 Thread Sanford Stein


Andre, Christopher, and Konstantin,

Thank you for your prompt responses and your suggestions.

I apologize for not indicating my Tomcat version -- it is 5.5.23.  My OS 
is RHEL 5.6.
I am not intentionally sending HTML e-mails--perhaps my Thunderbird 
client is doing something of which I am unaware.


By escaping my punctuation characters, I was able to get 
\*\.googlebot\.com  and other such addresses to work.


I tried to use the filter feature to restrict an IP address to certain 
class files only.  Here is what I put into web.xml:


filter
filter-nameRemote Address Filter/filter-name
filter-classorg.apache.catalina.filters.RemoteAddrFilter/filter-class
init-param
param-namedeny/param-name
param-value24\.13\.86\.5/param-value
/init-param
/filter
filter-mapping
filter-nameRemote Address Filter/filter-name
url-pattern/CyberHTML/url-pattern
/filter-mapping
filter
filter-nameRemote Address Filter 2/filter-name
filter-classorg.apache.catalina.filters.RemoteAddrFilter/filter-class
init-param
param-nameallow/param-name
param-value24\.13\.86\.5/param-value
/init-param
/filter
filter-mapping
filter-nameRemote Address Filter 2/filter-name
url-pattern/TunnelServlet/url-pattern
filter-mapping

The result was that 24.13.86.5 was denied access to BOTH servlets.  
(They are both in the 'classes' subdirectory.)  If someone can see 
anything I am doing wrong, I would appreciate your response.


Thanks,
Sanford Stein
CyberTools Inc.

Re: Denying IPs using the Valve command in context.xml


Francis GALIEGUE wrote:

On Tue, Oct 4, 2011 at 21:08, Christopher Schultz
ch...@christopherschultz.net wrote:
[...]

- From the docs:

If this attribute [allow] is specified, the remote address MUST match
for this request to be accepted.

If this attribute [deny] is specified, the remote address MUST NOT
match for this request to be accepted.

I don't think Matacher.lookingAt is appropriate for this kind of checking.



Well, it depends on the definition of match, I guess. For me, a
regex matches an input if it matches anywhere in the input! Which is
pretty much the definition of regex matching, and which is why Java's
.matches() methods are misnomers...

I am not sure that I follow the depths of the Java implementation of all of this, but 
please note that \.googlebot\.com$ is a regexp /anchored/ at the end of the string.
In other words, I would be surprised (and disappointed) if this did not match the 
hostnames bot1.googlebot.com and bot123.bots.googlebot.com e.g.




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

Re: Denying IPs using the Valve command in context.xml

On Tue, Oct 4, 2011 at 21:40, André Warnier a...@ice-sa.com wrote:
[...]

 I am not sure that I follow the depths of the Java implementation of all of
 this, but please note that \.googlebot\.com$ is a regexp /anchored/ at the
 end of the string.
 In other words, I would be surprised (and disappointed) if this did not
 match the hostnames bot1.googlebot.com and bot123.bots.googlebot.com

It's quite simple really: .matches(), which is used, anchors the regex
at the beginning and end. .matches(re) is equivalent to
.lookingAt(^re$), even if your re is already anchored.

Unfortunately, this method's misleading name and the prevalence of
Java has led a lot of people to believe that regex matching was done
on the whole input, which is of course false.

-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
f...@one2team.com
40 avenue Raymond Poincaré
75116 Paris

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

Re: [OT] Denying IPs using the Valve command in context.xml


Sanford Stein wrote:
...
I am not intentionally sending HTML e-mails--perhaps my Thunderbird 
client is doing something of which I am unaware.


You can set this either in your global preferences for sending emails 
(Options..Composition..General..Send Options), and/or specifically in your address book, 
for the address users@tomcat.apache.org.

(prefers to receive messages formatted as.. Plain text)





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

Re: Denying IPs using the Valve command in context.xml

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sanford,

On 10/4/2011 3:40 PM, Sanford Stein wrote:
 I am not intentionally sending HTML e-mails--perhaps my
 Thunderbird client is doing something of which I am unaware.

You can configure tb to send plain-text to certain recipients.
Consider adding users@tomcat.apache.org to such a list.

 By escaping my punctuation characters, I was able to get 
 \*\.googlebot\.com  and other such addresses to work.

Good.

 I tried to use the filter feature to restrict an IP address to
 certain class files only.  Here is what I put into web.xml:
 
 filter filter-nameRemote Address Filter/filter-name 
 filter-classorg.apache.catalina.filters.RemoteAddrFilter/filter-class

 
init-param
 param-namedeny/param-name 
 param-value24\.13\.86\.5/param-value /init-param /filter 
 filter-mapping filter-nameRemote Address Filter/filter-name 
 url-pattern/CyberHTML/url-pattern /filter-mapping filter 
 filter-nameRemote Address Filter 2/filter-name 
 filter-classorg.apache.catalina.filters.RemoteAddrFilter/filter-class

 
init-param
 param-nameallow/param-name 
 param-value24\.13\.86\.5/param-value /init-param /filter 
 filter-mapping filter-nameRemote Address Filter
 2/filter-name url-pattern/TunnelServlet/url-pattern 
 filter-mapping
 
 The result was that 24.13.86.5 was denied access to BOTH servlets.
  (They are both in the 'classes' subdirectory.)  If someone can
 see anything I am doing wrong, I would appreciate your response.

Note that you have mapped the filters by URL and not by servlet. If
you want to map by servlet and not by URL, you can use servlet-name
instead of url-mapping.

I can't explain why you are getting denials under both URLs, though.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6Lb3YACgkQ9CaO5/Lv0PDf8gCbBoE2/LpouKwuWH5hzFTzMy2R
makAn2xT/0Dq9E4nopGLpPZ9E36abgs6
=HV8Y
-END PGP SIGNATURE-

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

Re: Denying IPs using the Valve command in context.xml


Francis GALIEGUE wrote:

On Tue, Oct 4, 2011 at 21:40, André Warnier a...@ice-sa.com wrote:
[...]

I am not sure that I follow the depths of the Java implementation of all of
this, but please note that \.googlebot\.com$ is a regexp /anchored/ at the
end of the string.
In other words, I would be surprised (and disappointed) if this did not
match the hostnames bot1.googlebot.com and bot123.bots.googlebot.com


It's quite simple really: .matches(), which is used, anchors the regex
at the beginning and end. .matches(re) is equivalent to
.lookingAt(^re$), even if your re is already anchored.

Unfortunately, this method's misleading name and the prevalence of
Java has led a lot of people to believe that regex matching was done
on the whole input, which is of course false.

Having now consulted the java.util.regex package documentation (as mentioned in the Tomcat 
Valves documentation), these are my own remarks :


I agree with Francis that the way the documentation is written, is confusing for anyone 
not dedicating his life to Java programming (like the sysadmins and other perl programmers 
who have to use this to configure Tomcat). In classical regex usage, if you want something 
anchored, you have to say so explicitly.  In classical regex usage, if you do use anchors 
such as ^ and $, you expect them to take effect, and not to be silently ignored.


One thing that strikes me, is in :
http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html
it says Instances of this class are immutable and are safe for use by multiple concurrent 
threads. Instances of the Matcher class are not safe for such use.

(But the Matcher class itself seems silent about this).

And, it seems that the Pattern class, and its own .matches() method, does work in the way 
that a non-exclusively-java programmer would expect, anchors and all.


So my question is : which of Matcher or Pattern is really used in the Valve's 
code ?

Furthermore, about the Tomcat Valve documentation, I would opine :

- either the documentation remains as it is, and in the code, it should use the Pattern 
class for matching (and thus not automatically anchor, but allow the usage of explicit 
anchors in the provided patterns for allow and deny).


- or the documentation should be amended to indicate that the expression provided for 
allow and deny is already automatically anchored at the beginning and end of the string.

(And also that this is not thread-safe, and may occasionally miss a host ?)



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

Re: Denying IPs using the Valve command in context.xml

On Tue, Oct 4, 2011 at 22:50, André Warnier a...@ice-sa.com wrote:
[...]

 So my question is : which of Matcher or Pattern is really used in the
 Valve's code ?


You use a Matcher to match. A Pattern is only the compiled form of a regex:

final String re = ^;
final Pattern p = Pattern.compile(re);
final Matcher m = p.matcher(myinput);

if (m.matches())
// etc

So, the fact that Matcher instances are not thread safe is not really
the problem.

[...]

 - or the documentation should be amended to indicate that the expression
 provided for allow and deny is already automatically anchored at the
 beginning and end of the string.

Agreed. The Tomcat documentation also suffered the same problem (wrt
regex usage in its regex-mapper IIRC) and I've had the doc fixed :p

-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
f...@one2team.com
40 avenue Raymond Poincaré
75116 Paris

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

Re: Denying IPs using the Valve command in context.xml

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 10/4/2011 4:50 PM, André Warnier wrote:
 I agree with Francis that the way the documentation is written, is 
 confusing for anyone not dedicating his life to Java programming
 (like the sysadmins and other perl programmers who have to use this
 to configure Tomcat). In classical regex usage, if you want
 something anchored, you have to say so explicitly.  In classical
 regex usage, if you do use anchors such as ^ and $, you expect them
 to take effect, and not to be silently ignored.

I suspect it's not going to change, as that would be an incompatible
change. Since it's security-related, it's not something to be changed
lightly.

 And, it seems that the Pattern class, and its own .matches()
 method, does work in the way that a non-exclusively-java programmer
 would expect, anchors and all.

Does it?


Compiles the given regular expression and attempts to match the given
input against it.

An invocation of this convenience method of the form

 Pattern.matches(regex, input);

behaves in exactly the same way as the expression

 Pattern.compile(regex).matcher(input).matches()

If a pattern is to be used multiple times, compiling it once and
reusing it will be more efficient than invoking this method each time.


 So my question is : which of Matcher or Pattern is really used in
 the Valve's code ?

You could read the code :)

 Furthermore, about the Tomcat Valve documentation, I would opine :
 
 - either the documentation remains as it is, and in the code, it
 should use the Pattern class for matching (and thus not
 automatically anchor, but allow the usage of explicit anchors in
 the provided patterns for allow and deny).

Not going to change the code (see above). Also, Pattern.matches is
static and re-compiles the pattern every time. That's also not going
to change.

 - or the documentation should be amended to indicate that the
 expression provided for allow and deny is already automatically
 anchored at the beginning and end of the string. (And also that
 this is not thread-safe, and may occasionally miss a host ?)

Documentation patches are always welcome. Thread-safety is not an
issue (hint:read the code).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6Lc4wACgkQ9CaO5/Lv0PCySgCgkLqSiAVx4D/F/7RTbKopzQBf
hScAn3VAYSNyoHzgi5jg4h3nDAat0bQt
=QpMq
-END PGP SIGNATURE-

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

Re: Should Form Authentication Valve restore request body on a PUT?

2011-10-04 Thread Nicholas Sushkin

https://issues.apache.org/bugzilla/show_bug.cgi?id=51940

I left all the flags at their default settings.

Thanks!

On Saturday, October 01, 2011 07:20:21 Mark Thomas wrote:
 On 30/09/2011 17:09, Nicholas Sushkin wrote:
  Mark, Chris, thanks for the review.
  
  
  Should filing a bug be my next step, then?
 
 Please.
 
 Mark
 
  On Friday, September 30, 2011 13:10:55 Mark Thomas wrote:
   Basically my thinking is that you handle POST, shouldn't you also
   
   implement PUT the same way, to be consistent?
  
  I'd have no objection so the proposed change.
  
  
  
  Mark
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
-- 
Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
Open Finance - Secure, Accurate, Industrial Strength Aggregation
http://www.openfinance.com

smime.p7s
Description: S/MIME cryptographic signature

Re: Denying IPs using the Valve command in context.xml


Christopher Schultz wrote:
...




And, it seems that the Pattern class, and its own .matches()
method, does work in the way that a non-exclusively-java programmer
would expect, anchors and all.


Does it?



Yes, because if one defines e.g. a Pattern ^abcdef and uses it via
yesno = Pattern.matches(^abcdef,input);
it will actually match the pattern at the beginning of the string only, which is what one 
would expect.  Thus


Pattern.matches(^abc,abcdef);

would return true, while this :

Pattern.compile(^abc).matcher(abcdef).matches()

would return false (according to what I read in the documentation of 
Matcher.matches()).
Not so ?




So my question is : which of Matcher or Pattern is really used in
the Valve's code ?


You could read the code :)



Do you mean to say that trying to configure Tomcat according to the online documentation, 
with the purpose of using it as a servlet container, is reserved exclusively for java 
programmers ?

;-)

...

I guess that what I have trouble understanding here, is how the Java regex library can go 
about allowing to create a Pattern like ^abc, and then using it in a Matcher.matches() 
method, completely ignoring the anchors which it accepted in the Pattern and silently 
inserting its own.


Unless apparently, if you first call
Matcher.useAnchoringBounds(true)

/then/ it would respect the anchors in the Pattern.
Or ?

I must admit that I cannot really be sure of my interpretation of the useAnchoringBounds 
method :


quote :

public Matcher useAnchoringBounds(boolean b)

Sets the anchoring of region bounds for this matcher.

Invoking this method with an argument of true will set this matcher to use anchoring 
bounds. If the boolean argument is false, then non-anchoring bounds will be used.


Using anchoring bounds, the boundaries of this matcher's region match anchors such as 
^ and $.


Without anchoring bounds, the boundaries of this matcher's region will not match 
anchors such as ^ and $.


By default, a matcher uses anchoring region boundaries.

unquote

The above would seem to indicate that by default, anchors like ^ and $ (in the Pattern ?) 
are being respected.

But then, how come they are not, in the allow/deny of the Valve ?
Does the Valve code itself strip any provided anchors, and force ^ and $ around the 
expression provided in the allow/deny attributes ?




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

Re: Denying IPs using the Valve command in context.xml

On Tue, Oct 4, 2011 at 23:48, André Warnier a...@ice-sa.com wrote:

 And, it seems that the Pattern class, and its own .matches()
 method, does work in the way that a non-exclusively-java programmer
 would expect, anchors and all.

 Does it?


 Yes, because if one defines e.g. a Pattern ^abcdef and uses it via
 yesno = Pattern.matches(^abcdef,input);
 it will actually match the pattern at the beginning of the string only,
 which is what one would expect.  Thus

 Pattern.matches(^abc,abcdef);

 would return true, while this :

 Pattern.compile(^abc).matcher(abcdef).matches()

 would return false (according to what I read in the documentation of
 Matcher.matches()).
 Not so ?



Well, no, and here you see the incoherency of Java vocabulary vs the
rest of the regex world ;)

The Javadoc should really read attempts to match the _whole_
input.

Bah. Too late to fix things...

-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
f...@one2team.com
40 avenue Raymond Poincaré
75116 Paris

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

Re: Denying IPs using the Valve command in context.xml