[jetty-dev] Fwd: Major security issue or misconfiguration?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[jetty-dev] Fwd: Major security issue or misconfiguration?

Matthew Painter
Hi all,

Disclosure: This is a cross post from the users list where no-one had any suggestions - I hope you as devs may have more insight? :)

I am using Jetty7.5.1+OSGi, exposing servlets by using Web-ContextPath.

Say my path is Web-ContextPath is /foo and I have class bar.FooBar, then I can retrieve the class file by going to:


and I infact can list the whole directory and subdirectory by visiting:


If I have a servlet mapped to /* then this does not happen.

This seems like an enormous issue. It hasn't happened previously, and I can't seem to find what has changed.

The previous behaviour was to 404 on requesting anything but servlet mappings, or assets that are not class files and not in META-INF or WEB-INF.

Can anyone shed any light on why all the class files in the bundle are exposed?

Thanks!

Matt


_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Fwd: Major security issue or misconfiguration?

Jesse McConnell
Hugues is your best bet for an answer.

--
jesse mcconnell
[hidden email]


On Wed, Jun 27, 2012 at 4:03 PM, Matthew Painter
<[hidden email]> wrote:

> Hi all,
>
> Disclosure: This is a cross post from the users list where no-one had any
> suggestions - I hope you as devs may have more insight? :)
>
> I am using Jetty7.5.1+OSGi, exposing servlets by using Web-ContextPath.
>
> Say my path is Web-ContextPath is /foo and I have class bar.FooBar, then I
> can retrieve the class file by going to:
>
> http://my.server/foo/bar/FooBar.class
>
> and I infact can list the whole directory and subdirectory by visiting:
>
> http://my.server/foo
>
> If I have a servlet mapped to /* then this does not happen.
>
> This seems like an enormous issue. It hasn't happened previously, and I
> can't seem to find what has changed.
>
> The previous behaviour was to 404 on requesting anything but servlet
> mappings, or assets that are not class files and not in META-INF or WEB-INF.
>
> Can anyone shed any light on why all the class files in the bundle are
> exposed?
>
> Thanks!
>
> Matt
>
>
> _______________________________________________
> jetty-dev mailing list
> [hidden email]
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Fwd: Major security issue or misconfiguration?

Matthew Painter
Thanks Jesse :)

I tracked down what I think is the issue in org.eclipse.jetty.osgi.boot.internal.webapp.JettyContextHandlerExtender:

134            // support for OSGi-RFC66; disclaimer, no access to the actual
135            // (draft) of the spec: just a couple of posts on the
136            // world-wide-web.
137            URL rfc66Webxml = bundle.getEntry("/WEB-INF/web.xml");
138            if (rfc66Webxml == null)
139            {
140                return;// no webapp in here
141            }
142            // this is risky: should we make sure that there is no classes and
143            // jars directly available
144            // at the root of the of the bundle: otherwise they are accessible
145            // through the browser. we should enforce that the whole classpath
146            // is
147            // pointing to files and folders inside WEB-INF. We should
148            // filter-out
149            // META-INF too
150            String rfc66ContextPath = getWebContextPath(bundle,dic);
151            try
152            {
153                JettyBootstrapActivator.registerWebapplication(bundle,".",rfc66ContextPath);
154            }
155            catch (Throwable e)
156            {
157                // TODO Auto-generated catch block
158                e.printStackTrace();
159            }

When eclipse builds the bundles, the class files are indeed in the root and so are visible as static resources. The workaround would be to have eclipse put the files within WEB-INF/classes, although I cannot see how this is possible within eclipse/tycho at the moment.

This seems to be by default a massive security issue when using eclipse generated web bundles with Jetty RT. I would also suggest it might be a good idea to not have directory browsing on by default in the webdefault.xml?

What do you think is the best way forward Hugues / everyone else? 

It appears to also affect my previous installation, but due to the jetty temporary webapp directories being cleaned by the system (and this not being picked up), it was giving 404s - I think this may be a separate bug/issue the simple workaround being (in theory) to set Java up with a different default temp file location that is not interfered with.

Thanks for your time :)

Matt

On Wed, Jun 27, 2012 at 10:32 PM, Jesse McConnell <[hidden email]> wrote:
Hugues is your best bet for an answer.

--
jesse mcconnell
[hidden email]


On Wed, Jun 27, 2012 at 4:03 PM, Matthew Painter
<[hidden email]> wrote:
> Hi all,
>
> Disclosure: This is a cross post from the users list where no-one had any
> suggestions - I hope you as devs may have more insight? :)
>
> I am using Jetty7.5.1+OSGi, exposing servlets by using Web-ContextPath.
>
> Say my path is Web-ContextPath is /foo and I have class bar.FooBar, then I
> can retrieve the class file by going to:
>
> http://my.server/foo/bar/FooBar.class
>
> and I infact can list the whole directory and subdirectory by visiting:
>
> http://my.server/foo
>
> If I have a servlet mapped to /* then this does not happen.
>
> This seems like an enormous issue. It hasn't happened previously, and I
> can't seem to find what has changed.
>
> The previous behaviour was to 404 on requesting anything but servlet
> mappings, or assets that are not class files and not in META-INF or WEB-INF.
>
> Can anyone shed any light on why all the class files in the bundle are
> exposed?
>
> Thanks!
>
> Matt
>
>
> _______________________________________________
> jetty-dev mailing list
> [hidden email]
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Fwd: Major security issue or misconfiguration?

Hugues Malphettes
Hi Matthew,

Thanks for the report.

Indeed the best workaround is to generate them in WEB-INF/classes.
In theory tycho supports it: https://issues.sonatype.org/browse/TYCHO-328
But I just spend 50 minutes trying it: it does not work for me anymore.

Another workaround consists of placing your webapp folder in a nested folder.

For example 'WebContent'
Add this entry to the manifest:
Jetty-WarFolderPath: WebContent

Then place your web.xml inside WebContent/WEB-INF
and your static content inside WebContent

In your build.properties:
bin.includes = META-INF/,\
               WebContent/,\
               .

In any case I filed this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=383707

I'm not sure what should be the outcome of this: filter *.class by default ?
What if in fact you do want to server those?
How about all the other files: properties, anything could be inside the classes?

Hugues

On Thu, Jun 28, 2012 at 6:19 AM, Matthew Painter
<[hidden email]> wrote:

> Thanks Jesse :)
>
> I tracked down what I think is the issue
> in org.eclipse.jetty.osgi.boot.internal.webapp.JettyContextHandlerExtender:
>
> 134            // support for OSGi-RFC66; disclaimer, no access to the
> actual
> 135            // (draft) of the spec: just a couple of posts on the
> 136            // world-wide-web.
> 137            URL rfc66Webxml = bundle.getEntry("/WEB-INF/web.xml");
> 138            if (rfc66Webxml == null)
> 139            {
> 140                return;// no webapp in here
> 141            }
> 142            // this is risky: should we make sure that there is no
> classes and
> 143            // jars directly available
> 144            // at the root of the of the bundle: otherwise they are
> accessible
> 145            // through the browser. we should enforce that the whole
> classpath
> 146            // is
> 147            // pointing to files and folders inside WEB-INF. We should
> 148            // filter-out
> 149            // META-INF too
> 150            String rfc66ContextPath = getWebContextPath(bundle,dic);
> 151            try
> 152            {
> 153
>  JettyBootstrapActivator.registerWebapplication(bundle,".",rfc66ContextPath);
> 154            }
> 155            catch (Throwable e)
> 156            {
> 157                // TODO Auto-generated catch block
> 158                e.printStackTrace();
> 159            }
>
> When eclipse builds the bundles, the class files are indeed in the root and
> so are visible as static resources. The workaround would be to have eclipse
> put the files within WEB-INF/classes, although I cannot see how this is
> possible within eclipse/tycho at the moment.
>
> This seems to be by default a massive security issue when using eclipse
> generated web bundles with Jetty RT. I would also suggest it might be a good
> idea to not have directory browsing on by default in the webdefault.xml?
>
> What do you think is the best way forward Hugues / everyone else?
>
> It appears to also affect my previous installation, but due to the jetty
> temporary webapp directories being cleaned by the system (and this not being
> picked up), it was giving 404s - I think this may be a separate bug/issue
> the simple workaround being (in theory) to set Java up with a different
> default temp file location that is not interfered with.
>
> Thanks for your time :)
>
> Matt
>
>
> On Wed, Jun 27, 2012 at 10:32 PM, Jesse McConnell
> <[hidden email]> wrote:
>>
>> Hugues is your best bet for an answer.
>>
>> --
>> jesse mcconnell
>> [hidden email]
>>
>>
>> On Wed, Jun 27, 2012 at 4:03 PM, Matthew Painter
>> <[hidden email]> wrote:
>> > Hi all,
>> >
>> > Disclosure: This is a cross post from the users list where no-one had
>> > any
>> > suggestions - I hope you as devs may have more insight? :)
>> >
>> > I am using Jetty7.5.1+OSGi, exposing servlets by using Web-ContextPath.
>> >
>> > Say my path is Web-ContextPath is /foo and I have class bar.FooBar, then
>> > I
>> > can retrieve the class file by going to:
>> >
>> > http://my.server/foo/bar/FooBar.class
>> >
>> > and I infact can list the whole directory and subdirectory by visiting:
>> >
>> > http://my.server/foo
>> >
>> > If I have a servlet mapped to /* then this does not happen.
>> >
>> > This seems like an enormous issue. It hasn't happened previously, and I
>> > can't seem to find what has changed.
>> >
>> > The previous behaviour was to 404 on requesting anything but servlet
>> > mappings, or assets that are not class files and not in META-INF or
>> > WEB-INF.
>> >
>> > Can anyone shed any light on why all the class files in the bundle are
>> > exposed?
>> >
>> > Thanks!
>> >
>> > Matt
>> >
>> >
>> > _______________________________________________
>> > jetty-dev mailing list
>> > [hidden email]
>> > https://dev.eclipse.org/mailman/listinfo/jetty-dev
>> >
>> _______________________________________________
>> jetty-dev mailing list
>> [hidden email]
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
>
>
> _______________________________________________
> jetty-dev mailing list
> [hidden email]
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Fwd: Major security issue or misconfiguration?

Matthew Painter
Thanks so much for your input and testing Hugues.

I think to be pragmatic I will go with using  Jetty-WarFolderPath: WebContent solution. 

It is probably more of a matter of full disclosure I guess, with the tutorials showing using this. Trying to filter, as  you point out, would be impossible without letting users specify a inclusion/exclusion filter.

I am happy to take an action to do this if it is thought the best way forward?

On Thu, Jun 28, 2012 at 3:08 AM, Hugues Malphettes <[hidden email]> wrote:
Hi Matthew,

Thanks for the report.

Indeed the best workaround is to generate them in WEB-INF/classes.
In theory tycho supports it: https://issues.sonatype.org/browse/TYCHO-328
But I just spend 50 minutes trying it: it does not work for me anymore.

Another workaround consists of placing your webapp folder in a nested folder.

For example 'WebContent'
Add this entry to the manifest:
Jetty-WarFolderPath: WebContent

Then place your web.xml inside WebContent/WEB-INF
and your static content inside WebContent

In your build.properties:
bin.includes = META-INF/,\
              WebContent/,\
              .

In any case I filed this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=383707

I'm not sure what should be the outcome of this: filter *.class by default ?
What if in fact you do want to server those?
How about all the other files: properties, anything could be inside the classes?

Hugues

On Thu, Jun 28, 2012 at 6:19 AM, Matthew Painter
<[hidden email]> wrote:
> Thanks Jesse :)
>
> I tracked down what I think is the issue
> in org.eclipse.jetty.osgi.boot.internal.webapp.JettyContextHandlerExtender:
>
> 134            // support for OSGi-RFC66; disclaimer, no access to the
> actual
> 135            // (draft) of the spec: just a couple of posts on the
> 136            // world-wide-web.
> 137            URL rfc66Webxml = bundle.getEntry("/WEB-INF/web.xml");
> 138            if (rfc66Webxml == null)
> 139            {
> 140                return;// no webapp in here
> 141            }
> 142            // this is risky: should we make sure that there is no
> classes and
> 143            // jars directly available
> 144            // at the root of the of the bundle: otherwise they are
> accessible
> 145            // through the browser. we should enforce that the whole
> classpath
> 146            // is
> 147            // pointing to files and folders inside WEB-INF. We should
> 148            // filter-out
> 149            // META-INF too
> 150            String rfc66ContextPath = getWebContextPath(bundle,dic);
> 151            try
> 152            {
> 153
>  JettyBootstrapActivator.registerWebapplication(bundle,".",rfc66ContextPath);
> 154            }
> 155            catch (Throwable e)
> 156            {
> 157                // TODO Auto-generated catch block
> 158                e.printStackTrace();
> 159            }
>
> When eclipse builds the bundles, the class files are indeed in the root and
> so are visible as static resources. The workaround would be to have eclipse
> put the files within WEB-INF/classes, although I cannot see how this is
> possible within eclipse/tycho at the moment.
>
> This seems to be by default a massive security issue when using eclipse
> generated web bundles with Jetty RT. I would also suggest it might be a good
> idea to not have directory browsing on by default in the webdefault.xml?
>
> What do you think is the best way forward Hugues / everyone else?
>
> It appears to also affect my previous installation, but due to the jetty
> temporary webapp directories being cleaned by the system (and this not being
> picked up), it was giving 404s - I think this may be a separate bug/issue
> the simple workaround being (in theory) to set Java up with a different
> default temp file location that is not interfered with.
>
> Thanks for your time :)
>
> Matt
>
>
> On Wed, Jun 27, 2012 at 10:32 PM, Jesse McConnell
> <[hidden email]> wrote:
>>
>> Hugues is your best bet for an answer.
>>
>> --
>> jesse mcconnell
>> [hidden email]
>>
>>
>> On Wed, Jun 27, 2012 at 4:03 PM, Matthew Painter
>> <[hidden email]> wrote:
>> > Hi all,
>> >
>> > Disclosure: This is a cross post from the users list where no-one had
>> > any
>> > suggestions - I hope you as devs may have more insight? :)
>> >
>> > I am using Jetty7.5.1+OSGi, exposing servlets by using Web-ContextPath.
>> >
>> > Say my path is Web-ContextPath is /foo and I have class bar.FooBar, then
>> > I
>> > can retrieve the class file by going to:
>> >
>> > http://my.server/foo/bar/FooBar.class
>> >
>> > and I infact can list the whole directory and subdirectory by visiting:
>> >
>> > http://my.server/foo
>> >
>> > If I have a servlet mapped to /* then this does not happen.
>> >
>> > This seems like an enormous issue. It hasn't happened previously, and I
>> > can't seem to find what has changed.
>> >
>> > The previous behaviour was to 404 on requesting anything but servlet
>> > mappings, or assets that are not class files and not in META-INF or
>> > WEB-INF.
>> >
>> > Can anyone shed any light on why all the class files in the bundle are
>> > exposed?
>> >
>> > Thanks!
>> >
>> > Matt
>> >
>> >
>> > _______________________________________________
>> > jetty-dev mailing list
>> > [hidden email]
>> > https://dev.eclipse.org/mailman/listinfo/jetty-dev
>> >
>> _______________________________________________
>> jetty-dev mailing list
>> [hidden email]
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
>
>
> _______________________________________________
> jetty-dev mailing list
> [hidden email]
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Fwd: Major security issue or misconfiguration?

Matthew Painter
So, unfortunately, this doesn't work.

When the jar gets expanded out by jetty into a webapp folder (/tmp//jetty-0.0.0.0-8888-WebContent-_XXX-any-/webapp/), the folder is empty, and spring will not load beans etc.

Further the other option - making tycho compile into WEB-INF classes works BUT will only either compile into WEB-INF classes, OR include WEB-INF/web.xml:

no .class files, web.xml:

source.WEB-INF/classes/ = src/
output.WEB-INF/classes/ = target/classes
bin.includes = META-INF/,    \
               WEB-INF/classes/,
               assets/,
               WEB-INF/web.xml


.class files, no web.xml:

source.WEB-INF/classes/ = src/
output.WEB-INF/classes/ = target/classes
bin.includes = META-INF/,    \
               WEB-INF/classes/,
               assets/

I have the feeling it might be a case of a bug in Tycho here, so checking out the source now. 

On Thu, Jun 28, 2012 at 9:33 AM, Matthew Painter <[hidden email]> wrote:
Thanks so much for your input and testing Hugues.

I think to be pragmatic I will go with using  Jetty-WarFolderPath: WebContent solution. 

It is probably more of a matter of full disclosure I guess, with the tutorials showing using this. Trying to filter, as  you point out, would be impossible without letting users specify a inclusion/exclusion filter.

I am happy to take an action to do this if it is thought the best way forward?


On Thu, Jun 28, 2012 at 3:08 AM, Hugues Malphettes <[hidden email]> wrote:
Hi Matthew,

Thanks for the report.

Indeed the best workaround is to generate them in WEB-INF/classes.
In theory tycho supports it: https://issues.sonatype.org/browse/TYCHO-328
But I just spend 50 minutes trying it: it does not work for me anymore.

Another workaround consists of placing your webapp folder in a nested folder.

For example 'WebContent'
Add this entry to the manifest:
Jetty-WarFolderPath: WebContent

Then place your web.xml inside WebContent/WEB-INF
and your static content inside WebContent

In your build.properties:
bin.includes = META-INF/,\
              WebContent/,\
              .

In any case I filed this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=383707

I'm not sure what should be the outcome of this: filter *.class by default ?
What if in fact you do want to server those?
How about all the other files: properties, anything could be inside the classes?

Hugues

On Thu, Jun 28, 2012 at 6:19 AM, Matthew Painter
<[hidden email]> wrote:
> Thanks Jesse :)
>
> I tracked down what I think is the issue
> in org.eclipse.jetty.osgi.boot.internal.webapp.JettyContextHandlerExtender:
>
> 134            // support for OSGi-RFC66; disclaimer, no access to the
> actual
> 135            // (draft) of the spec: just a couple of posts on the
> 136            // world-wide-web.
> 137            URL rfc66Webxml = bundle.getEntry("/WEB-INF/web.xml");
> 138            if (rfc66Webxml == null)
> 139            {
> 140                return;// no webapp in here
> 141            }
> 142            // this is risky: should we make sure that there is no
> classes and
> 143            // jars directly available
> 144            // at the root of the of the bundle: otherwise they are
> accessible
> 145            // through the browser. we should enforce that the whole
> classpath
> 146            // is
> 147            // pointing to files and folders inside WEB-INF. We should
> 148            // filter-out
> 149            // META-INF too
> 150            String rfc66ContextPath = getWebContextPath(bundle,dic);
> 151            try
> 152            {
> 153
>  JettyBootstrapActivator.registerWebapplication(bundle,".",rfc66ContextPath);
> 154            }
> 155            catch (Throwable e)
> 156            {
> 157                // TODO Auto-generated catch block
> 158                e.printStackTrace();
> 159            }
>
> When eclipse builds the bundles, the class files are indeed in the root and
> so are visible as static resources. The workaround would be to have eclipse
> put the files within WEB-INF/classes, although I cannot see how this is
> possible within eclipse/tycho at the moment.
>
> This seems to be by default a massive security issue when using eclipse
> generated web bundles with Jetty RT. I would also suggest it might be a good
> idea to not have directory browsing on by default in the webdefault.xml?
>
> What do you think is the best way forward Hugues / everyone else?
>
> It appears to also affect my previous installation, but due to the jetty
> temporary webapp directories being cleaned by the system (and this not being
> picked up), it was giving 404s - I think this may be a separate bug/issue
> the simple workaround being (in theory) to set Java up with a different
> default temp file location that is not interfered with.
>
> Thanks for your time :)
>
> Matt
>
>
> On Wed, Jun 27, 2012 at 10:32 PM, Jesse McConnell
> <[hidden email]> wrote:
>>
>> Hugues is your best bet for an answer.
>>
>> --
>> jesse mcconnell
>> [hidden email]
>>
>>
>> On Wed, Jun 27, 2012 at 4:03 PM, Matthew Painter
>> <[hidden email]> wrote:
>> > Hi all,
>> >
>> > Disclosure: This is a cross post from the users list where no-one had
>> > any
>> > suggestions - I hope you as devs may have more insight? :)
>> >
>> > I am using Jetty7.5.1+OSGi, exposing servlets by using Web-ContextPath.
>> >
>> > Say my path is Web-ContextPath is /foo and I have class bar.FooBar, then
>> > I
>> > can retrieve the class file by going to:
>> >
>> > http://my.server/foo/bar/FooBar.class
>> >
>> > and I infact can list the whole directory and subdirectory by visiting:
>> >
>> > http://my.server/foo
>> >
>> > If I have a servlet mapped to /* then this does not happen.
>> >
>> > This seems like an enormous issue. It hasn't happened previously, and I
>> > can't seem to find what has changed.
>> >
>> > The previous behaviour was to 404 on requesting anything but servlet
>> > mappings, or assets that are not class files and not in META-INF or
>> > WEB-INF.
>> >
>> > Can anyone shed any light on why all the class files in the bundle are
>> > exposed?
>> >
>> > Thanks!
>> >
>> > Matt
>> >
>> >
>> > _______________________________________________
>> > jetty-dev mailing list
>> > [hidden email]
>> > https://dev.eclipse.org/mailman/listinfo/jetty-dev
>> >
>> _______________________________________________
>> jetty-dev mailing list
>> [hidden email]
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
>
>
> _______________________________________________
> jetty-dev mailing list
> [hidden email]
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev



_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Fwd: Major security issue or misconfiguration?

Hugues Malphettes
Thanks a lot for the feedback Matthew.

On Thu, Jun 28, 2012 at 10:08 PM, Matthew Painter
<[hidden email]> wrote:
> So, unfortunately, this doesn't work.
In fact we are using the "Jetty-WarFolderPath: WebContent" for all our
internal project and we are still using 7.*.
I'm preparing an example with a tycho build for it.

<snip>

> I have the feeling it might be a case of a bug in Tycho here, so checking
> out the source now.

Many thanks for the investigation with tycho.
Definitely sounds like a regression.

Best,
Hugues.

>
> Further the other option - making tycho compile into WEB-INF classes works
> BUT will only either compile into WEB-INF classes, OR include
> WEB-INF/web.xml:
>
> no .class files, web.xml:
>
> source.WEB-INF/classes/ = src/
> output.WEB-INF/classes/ = target/classes
> bin.includes = META-INF/,    \
>                WEB-INF/classes/,
>                assets/,
>                WEB-INF/web.xml
>
>
>
> .class files, no web.xml:
>
> source.WEB-INF/classes/ = src/
> output.WEB-INF/classes/ = target/classes
> bin.includes = META-INF/,    \
>                WEB-INF/classes/,
>                assets/
>
>
> I have the feeling it might be a case of a bug in Tycho here, so checking
> out the source now.
>
> On Thu, Jun 28, 2012 at 9:33 AM, Matthew Painter
> <[hidden email]> wrote:
>>
>> Thanks so much for your input and testing Hugues.
>>
>> I think to be pragmatic I will go with using  Jetty-WarFolderPath:
>> WebContent solution.
>>
>> It is probably more of a matter of full disclosure I guess, with the
>> tutorials showing using this. Trying to filter, as  you point out, would be
>> impossible without letting users specify a inclusion/exclusion filter.
>>
>> I am happy to take an action to do this if it is thought the best way
>> forward?
>>
>>
>> On Thu, Jun 28, 2012 at 3:08 AM, Hugues Malphettes
>> <[hidden email]> wrote:
>>>
>>> Hi Matthew,
>>>
>>> Thanks for the report.
>>>
>>> Indeed the best workaround is to generate them in WEB-INF/classes.
>>> In theory tycho supports it: https://issues.sonatype.org/browse/TYCHO-328
>>> But I just spend 50 minutes trying it: it does not work for me anymore.
>>>
>>> Another workaround consists of placing your webapp folder in a nested
>>> folder.
>>>
>>> For example 'WebContent'
>>> Add this entry to the manifest:
>>> Jetty-WarFolderPath: WebContent
>>>
>>> Then place your web.xml inside WebContent/WEB-INF
>>> and your static content inside WebContent
>>>
>>> In your build.properties:
>>> bin.includes = META-INF/,\
>>>               WebContent/,\
>>>               .
>>>
>>> In any case I filed this bug:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=383707
>>>
>>> I'm not sure what should be the outcome of this: filter *.class by
>>> default ?
>>> What if in fact you do want to server those?
>>> How about all the other files: properties, anything could be inside the
>>> classes?
>>>
>>> Hugues
>>>
>>> On Thu, Jun 28, 2012 at 6:19 AM, Matthew Painter
>>> <[hidden email]> wrote:
>>> > Thanks Jesse :)
>>> >
>>> > I tracked down what I think is the issue
>>> >
>>> > in org.eclipse.jetty.osgi.boot.internal.webapp.JettyContextHandlerExtender:
>>> >
>>> > 134            // support for OSGi-RFC66; disclaimer, no access to the
>>> > actual
>>> > 135            // (draft) of the spec: just a couple of posts on the
>>> > 136            // world-wide-web.
>>> > 137            URL rfc66Webxml = bundle.getEntry("/WEB-INF/web.xml");
>>> > 138            if (rfc66Webxml == null)
>>> > 139            {
>>> > 140                return;// no webapp in here
>>> > 141            }
>>> > 142            // this is risky: should we make sure that there is no
>>> > classes and
>>> > 143            // jars directly available
>>> > 144            // at the root of the of the bundle: otherwise they are
>>> > accessible
>>> > 145            // through the browser. we should enforce that the whole
>>> > classpath
>>> > 146            // is
>>> > 147            // pointing to files and folders inside WEB-INF. We
>>> > should
>>> > 148            // filter-out
>>> > 149            // META-INF too
>>> > 150            String rfc66ContextPath = getWebContextPath(bundle,dic);
>>> > 151            try
>>> > 152            {
>>> > 153
>>> >
>>> >  JettyBootstrapActivator.registerWebapplication(bundle,".",rfc66ContextPath);
>>> > 154            }
>>> > 155            catch (Throwable e)
>>> > 156            {
>>> > 157                // TODO Auto-generated catch block
>>> > 158                e.printStackTrace();
>>> > 159            }
>>> >
>>> > When eclipse builds the bundles, the class files are indeed in the root
>>> > and
>>> > so are visible as static resources. The workaround would be to have
>>> > eclipse
>>> > put the files within WEB-INF/classes, although I cannot see how this is
>>> > possible within eclipse/tycho at the moment.
>>> >
>>> > This seems to be by default a massive security issue when using eclipse
>>> > generated web bundles with Jetty RT. I would also suggest it might be a
>>> > good
>>> > idea to not have directory browsing on by default in the
>>> > webdefault.xml?
>>> >
>>> > What do you think is the best way forward Hugues / everyone else?
>>> >
>>> > It appears to also affect my previous installation, but due to the
>>> > jetty
>>> > temporary webapp directories being cleaned by the system (and this not
>>> > being
>>> > picked up), it was giving 404s - I think this may be a separate
>>> > bug/issue
>>> > the simple workaround being (in theory) to set Java up with a different
>>> > default temp file location that is not interfered with.
>>> >
>>> > Thanks for your time :)
>>> >
>>> > Matt
>>> >
>>> >
>>> > On Wed, Jun 27, 2012 at 10:32 PM, Jesse McConnell
>>> > <[hidden email]> wrote:
>>> >>
>>> >> Hugues is your best bet for an answer.
>>> >>
>>> >> --
>>> >> jesse mcconnell
>>> >> [hidden email]
>>> >>
>>> >>
>>> >> On Wed, Jun 27, 2012 at 4:03 PM, Matthew Painter
>>> >> <[hidden email]> wrote:
>>> >> > Hi all,
>>> >> >
>>> >> > Disclosure: This is a cross post from the users list where no-one
>>> >> > had
>>> >> > any
>>> >> > suggestions - I hope you as devs may have more insight? :)
>>> >> >
>>> >> > I am using Jetty7.5.1+OSGi, exposing servlets by using
>>> >> > Web-ContextPath.
>>> >> >
>>> >> > Say my path is Web-ContextPath is /foo and I have class bar.FooBar,
>>> >> > then
>>> >> > I
>>> >> > can retrieve the class file by going to:
>>> >> >
>>> >> > http://my.server/foo/bar/FooBar.class
>>> >> >
>>> >> > and I infact can list the whole directory and subdirectory by
>>> >> > visiting:
>>> >> >
>>> >> > http://my.server/foo
>>> >> >
>>> >> > If I have a servlet mapped to /* then this does not happen.
>>> >> >
>>> >> > This seems like an enormous issue. It hasn't happened previously,
>>> >> > and I
>>> >> > can't seem to find what has changed.
>>> >> >
>>> >> > The previous behaviour was to 404 on requesting anything but servlet
>>> >> > mappings, or assets that are not class files and not in META-INF or
>>> >> > WEB-INF.
>>> >> >
>>> >> > Can anyone shed any light on why all the class files in the bundle
>>> >> > are
>>> >> > exposed?
>>> >> >
>>> >> > Thanks!
>>> >> >
>>> >> > Matt
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > jetty-dev mailing list
>>> >> > [hidden email]
>>> >> > https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>> >> >
>>> >> _______________________________________________
>>> >> jetty-dev mailing list
>>> >> [hidden email]
>>> >> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > jetty-dev mailing list
>>> > [hidden email]
>>> > https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>> >
>>> _______________________________________________
>>> jetty-dev mailing list
>>> [hidden email]
>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>
>>
>
>
> _______________________________________________
> jetty-dev mailing list
> [hidden email]
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Fwd: Major security issue or misconfiguration?

Hugues Malphettes
Matthew,

I did manage to get a web.xml and the classes output in WEB-INF/classes:
https://github.com/hmalphettes/tycho-example-projects/commit/50b1b2ca78ec8caea3bb5381da825359e4e5c1f6
Not an actual web-bundle, I started from the tycho example projects
and this is using the latest tycho-0.15.

I hope this helps.

Hugues

On Fri, Jun 29, 2012 at 11:24 AM, Hugues Malphettes
<[hidden email]> wrote:

> Thanks a lot for the feedback Matthew.
>
> On Thu, Jun 28, 2012 at 10:08 PM, Matthew Painter
> <[hidden email]> wrote:
>> So, unfortunately, this doesn't work.
> In fact we are using the "Jetty-WarFolderPath: WebContent" for all our
> internal project and we are still using 7.*.
> I'm preparing an example with a tycho build for it.
>
> <snip>
>
>> I have the feeling it might be a case of a bug in Tycho here, so checking
>> out the source now.
>
> Many thanks for the investigation with tycho.
> Definitely sounds like a regression.
>
> Best,
> Hugues.
>
>>
>> Further the other option - making tycho compile into WEB-INF classes works
>> BUT will only either compile into WEB-INF classes, OR include
>> WEB-INF/web.xml:
>>
>> no .class files, web.xml:
>>
>> source.WEB-INF/classes/ = src/
>> output.WEB-INF/classes/ = target/classes
>> bin.includes = META-INF/,    \
>>                WEB-INF/classes/,
>>                assets/,
>>                WEB-INF/web.xml
>>
>>
>>
>> .class files, no web.xml:
>>
>> source.WEB-INF/classes/ = src/
>> output.WEB-INF/classes/ = target/classes
>> bin.includes = META-INF/,    \
>>                WEB-INF/classes/,
>>                assets/
>>
>>
>> I have the feeling it might be a case of a bug in Tycho here, so checking
>> out the source now.
>>
>> On Thu, Jun 28, 2012 at 9:33 AM, Matthew Painter
>> <[hidden email]> wrote:
>>>
>>> Thanks so much for your input and testing Hugues.
>>>
>>> I think to be pragmatic I will go with using  Jetty-WarFolderPath:
>>> WebContent solution.
>>>
>>> It is probably more of a matter of full disclosure I guess, with the
>>> tutorials showing using this. Trying to filter, as  you point out, would be
>>> impossible without letting users specify a inclusion/exclusion filter.
>>>
>>> I am happy to take an action to do this if it is thought the best way
>>> forward?
>>>
>>>
>>> On Thu, Jun 28, 2012 at 3:08 AM, Hugues Malphettes
>>> <[hidden email]> wrote:
>>>>
>>>> Hi Matthew,
>>>>
>>>> Thanks for the report.
>>>>
>>>> Indeed the best workaround is to generate them in WEB-INF/classes.
>>>> In theory tycho supports it: https://issues.sonatype.org/browse/TYCHO-328
>>>> But I just spend 50 minutes trying it: it does not work for me anymore.
>>>>
>>>> Another workaround consists of placing your webapp folder in a nested
>>>> folder.
>>>>
>>>> For example 'WebContent'
>>>> Add this entry to the manifest:
>>>> Jetty-WarFolderPath: WebContent
>>>>
>>>> Then place your web.xml inside WebContent/WEB-INF
>>>> and your static content inside WebContent
>>>>
>>>> In your build.properties:
>>>> bin.includes = META-INF/,\
>>>>               WebContent/,\
>>>>               .
>>>>
>>>> In any case I filed this bug:
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=383707
>>>>
>>>> I'm not sure what should be the outcome of this: filter *.class by
>>>> default ?
>>>> What if in fact you do want to server those?
>>>> How about all the other files: properties, anything could be inside the
>>>> classes?
>>>>
>>>> Hugues
>>>>
>>>> On Thu, Jun 28, 2012 at 6:19 AM, Matthew Painter
>>>> <[hidden email]> wrote:
>>>> > Thanks Jesse :)
>>>> >
>>>> > I tracked down what I think is the issue
>>>> >
>>>> > in org.eclipse.jetty.osgi.boot.internal.webapp.JettyContextHandlerExtender:
>>>> >
>>>> > 134            // support for OSGi-RFC66; disclaimer, no access to the
>>>> > actual
>>>> > 135            // (draft) of the spec: just a couple of posts on the
>>>> > 136            // world-wide-web.
>>>> > 137            URL rfc66Webxml = bundle.getEntry("/WEB-INF/web.xml");
>>>> > 138            if (rfc66Webxml == null)
>>>> > 139            {
>>>> > 140                return;// no webapp in here
>>>> > 141            }
>>>> > 142            // this is risky: should we make sure that there is no
>>>> > classes and
>>>> > 143            // jars directly available
>>>> > 144            // at the root of the of the bundle: otherwise they are
>>>> > accessible
>>>> > 145            // through the browser. we should enforce that the whole
>>>> > classpath
>>>> > 146            // is
>>>> > 147            // pointing to files and folders inside WEB-INF. We
>>>> > should
>>>> > 148            // filter-out
>>>> > 149            // META-INF too
>>>> > 150            String rfc66ContextPath = getWebContextPath(bundle,dic);
>>>> > 151            try
>>>> > 152            {
>>>> > 153
>>>> >
>>>> >  JettyBootstrapActivator.registerWebapplication(bundle,".",rfc66ContextPath);
>>>> > 154            }
>>>> > 155            catch (Throwable e)
>>>> > 156            {
>>>> > 157                // TODO Auto-generated catch block
>>>> > 158                e.printStackTrace();
>>>> > 159            }
>>>> >
>>>> > When eclipse builds the bundles, the class files are indeed in the root
>>>> > and
>>>> > so are visible as static resources. The workaround would be to have
>>>> > eclipse
>>>> > put the files within WEB-INF/classes, although I cannot see how this is
>>>> > possible within eclipse/tycho at the moment.
>>>> >
>>>> > This seems to be by default a massive security issue when using eclipse
>>>> > generated web bundles with Jetty RT. I would also suggest it might be a
>>>> > good
>>>> > idea to not have directory browsing on by default in the
>>>> > webdefault.xml?
>>>> >
>>>> > What do you think is the best way forward Hugues / everyone else?
>>>> >
>>>> > It appears to also affect my previous installation, but due to the
>>>> > jetty
>>>> > temporary webapp directories being cleaned by the system (and this not
>>>> > being
>>>> > picked up), it was giving 404s - I think this may be a separate
>>>> > bug/issue
>>>> > the simple workaround being (in theory) to set Java up with a different
>>>> > default temp file location that is not interfered with.
>>>> >
>>>> > Thanks for your time :)
>>>> >
>>>> > Matt
>>>> >
>>>> >
>>>> > On Wed, Jun 27, 2012 at 10:32 PM, Jesse McConnell
>>>> > <[hidden email]> wrote:
>>>> >>
>>>> >> Hugues is your best bet for an answer.
>>>> >>
>>>> >> --
>>>> >> jesse mcconnell
>>>> >> [hidden email]
>>>> >>
>>>> >>
>>>> >> On Wed, Jun 27, 2012 at 4:03 PM, Matthew Painter
>>>> >> <[hidden email]> wrote:
>>>> >> > Hi all,
>>>> >> >
>>>> >> > Disclosure: This is a cross post from the users list where no-one
>>>> >> > had
>>>> >> > any
>>>> >> > suggestions - I hope you as devs may have more insight? :)
>>>> >> >
>>>> >> > I am using Jetty7.5.1+OSGi, exposing servlets by using
>>>> >> > Web-ContextPath.
>>>> >> >
>>>> >> > Say my path is Web-ContextPath is /foo and I have class bar.FooBar,
>>>> >> > then
>>>> >> > I
>>>> >> > can retrieve the class file by going to:
>>>> >> >
>>>> >> > http://my.server/foo/bar/FooBar.class
>>>> >> >
>>>> >> > and I infact can list the whole directory and subdirectory by
>>>> >> > visiting:
>>>> >> >
>>>> >> > http://my.server/foo
>>>> >> >
>>>> >> > If I have a servlet mapped to /* then this does not happen.
>>>> >> >
>>>> >> > This seems like an enormous issue. It hasn't happened previously,
>>>> >> > and I
>>>> >> > can't seem to find what has changed.
>>>> >> >
>>>> >> > The previous behaviour was to 404 on requesting anything but servlet
>>>> >> > mappings, or assets that are not class files and not in META-INF or
>>>> >> > WEB-INF.
>>>> >> >
>>>> >> > Can anyone shed any light on why all the class files in the bundle
>>>> >> > are
>>>> >> > exposed?
>>>> >> >
>>>> >> > Thanks!
>>>> >> >
>>>> >> > Matt
>>>> >> >
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > jetty-dev mailing list
>>>> >> > [hidden email]
>>>> >> > https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>> >> >
>>>> >> _______________________________________________
>>>> >> jetty-dev mailing list
>>>> >> [hidden email]
>>>> >> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > jetty-dev mailing list
>>>> > [hidden email]
>>>> > https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>> >
>>>> _______________________________________________
>>>> jetty-dev mailing list
>>>> [hidden email]
>>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> jetty-dev mailing list
>> [hidden email]
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>
_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Fwd: Major security issue or misconfiguration?

Matthew Painter
Thanks Hugues :)

I couldn't get it working with 0.15.0 using a bin-include of WEB-INF/
but could with WEB-INF/*

So this is solved for me for now :)

Thanks again, you've been very helpful!

On Fri, Jun 29, 2012 at 10:23 AM, Hugues Malphettes
<[hidden email]> wrote:

> Matthew,
>
> I did manage to get a web.xml and the classes output in WEB-INF/classes:
> https://github.com/hmalphettes/tycho-example-projects/commit/50b1b2ca78ec8caea3bb5381da825359e4e5c1f6
> Not an actual web-bundle, I started from the tycho example projects
> and this is using the latest tycho-0.15.
>
> I hope this helps.
>
> Hugues
>
> On Fri, Jun 29, 2012 at 11:24 AM, Hugues Malphettes
> <[hidden email]> wrote:
>> Thanks a lot for the feedback Matthew.
>>
>> On Thu, Jun 28, 2012 at 10:08 PM, Matthew Painter
>> <[hidden email]> wrote:
>>> So, unfortunately, this doesn't work.
>> In fact we are using the "Jetty-WarFolderPath: WebContent" for all our
>> internal project and we are still using 7.*.
>> I'm preparing an example with a tycho build for it.
>>
>> <snip>
>>
>>> I have the feeling it might be a case of a bug in Tycho here, so checking
>>> out the source now.
>>
>> Many thanks for the investigation with tycho.
>> Definitely sounds like a regression.
>>
>> Best,
>> Hugues.
>>
>>>
>>> Further the other option - making tycho compile into WEB-INF classes works
>>> BUT will only either compile into WEB-INF classes, OR include
>>> WEB-INF/web.xml:
>>>
>>> no .class files, web.xml:
>>>
>>> source.WEB-INF/classes/ = src/
>>> output.WEB-INF/classes/ = target/classes
>>> bin.includes = META-INF/,    \
>>>                WEB-INF/classes/,
>>>                assets/,
>>>                WEB-INF/web.xml
>>>
>>>
>>>
>>> .class files, no web.xml:
>>>
>>> source.WEB-INF/classes/ = src/
>>> output.WEB-INF/classes/ = target/classes
>>> bin.includes = META-INF/,    \
>>>                WEB-INF/classes/,
>>>                assets/
>>>
>>>
>>> I have the feeling it might be a case of a bug in Tycho here, so checking
>>> out the source now.
>>>
>>> On Thu, Jun 28, 2012 at 9:33 AM, Matthew Painter
>>> <[hidden email]> wrote:
>>>>
>>>> Thanks so much for your input and testing Hugues.
>>>>
>>>> I think to be pragmatic I will go with using  Jetty-WarFolderPath:
>>>> WebContent solution.
>>>>
>>>> It is probably more of a matter of full disclosure I guess, with the
>>>> tutorials showing using this. Trying to filter, as  you point out, would be
>>>> impossible without letting users specify a inclusion/exclusion filter.
>>>>
>>>> I am happy to take an action to do this if it is thought the best way
>>>> forward?
>>>>
>>>>
>>>> On Thu, Jun 28, 2012 at 3:08 AM, Hugues Malphettes
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Hi Matthew,
>>>>>
>>>>> Thanks for the report.
>>>>>
>>>>> Indeed the best workaround is to generate them in WEB-INF/classes.
>>>>> In theory tycho supports it: https://issues.sonatype.org/browse/TYCHO-328
>>>>> But I just spend 50 minutes trying it: it does not work for me anymore.
>>>>>
>>>>> Another workaround consists of placing your webapp folder in a nested
>>>>> folder.
>>>>>
>>>>> For example 'WebContent'
>>>>> Add this entry to the manifest:
>>>>> Jetty-WarFolderPath: WebContent
>>>>>
>>>>> Then place your web.xml inside WebContent/WEB-INF
>>>>> and your static content inside WebContent
>>>>>
>>>>> In your build.properties:
>>>>> bin.includes = META-INF/,\
>>>>>               WebContent/,\
>>>>>               .
>>>>>
>>>>> In any case I filed this bug:
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=383707
>>>>>
>>>>> I'm not sure what should be the outcome of this: filter *.class by
>>>>> default ?
>>>>> What if in fact you do want to server those?
>>>>> How about all the other files: properties, anything could be inside the
>>>>> classes?
>>>>>
>>>>> Hugues
>>>>>
>>>>> On Thu, Jun 28, 2012 at 6:19 AM, Matthew Painter
>>>>> <[hidden email]> wrote:
>>>>> > Thanks Jesse :)
>>>>> >
>>>>> > I tracked down what I think is the issue
>>>>> >
>>>>> > in org.eclipse.jetty.osgi.boot.internal.webapp.JettyContextHandlerExtender:
>>>>> >
>>>>> > 134            // support for OSGi-RFC66; disclaimer, no access to the
>>>>> > actual
>>>>> > 135            // (draft) of the spec: just a couple of posts on the
>>>>> > 136            // world-wide-web.
>>>>> > 137            URL rfc66Webxml = bundle.getEntry("/WEB-INF/web.xml");
>>>>> > 138            if (rfc66Webxml == null)
>>>>> > 139            {
>>>>> > 140                return;// no webapp in here
>>>>> > 141            }
>>>>> > 142            // this is risky: should we make sure that there is no
>>>>> > classes and
>>>>> > 143            // jars directly available
>>>>> > 144            // at the root of the of the bundle: otherwise they are
>>>>> > accessible
>>>>> > 145            // through the browser. we should enforce that the whole
>>>>> > classpath
>>>>> > 146            // is
>>>>> > 147            // pointing to files and folders inside WEB-INF. We
>>>>> > should
>>>>> > 148            // filter-out
>>>>> > 149            // META-INF too
>>>>> > 150            String rfc66ContextPath = getWebContextPath(bundle,dic);
>>>>> > 151            try
>>>>> > 152            {
>>>>> > 153
>>>>> >
>>>>> >  JettyBootstrapActivator.registerWebapplication(bundle,".",rfc66ContextPath);
>>>>> > 154            }
>>>>> > 155            catch (Throwable e)
>>>>> > 156            {
>>>>> > 157                // TODO Auto-generated catch block
>>>>> > 158                e.printStackTrace();
>>>>> > 159            }
>>>>> >
>>>>> > When eclipse builds the bundles, the class files are indeed in the root
>>>>> > and
>>>>> > so are visible as static resources. The workaround would be to have
>>>>> > eclipse
>>>>> > put the files within WEB-INF/classes, although I cannot see how this is
>>>>> > possible within eclipse/tycho at the moment.
>>>>> >
>>>>> > This seems to be by default a massive security issue when using eclipse
>>>>> > generated web bundles with Jetty RT. I would also suggest it might be a
>>>>> > good
>>>>> > idea to not have directory browsing on by default in the
>>>>> > webdefault.xml?
>>>>> >
>>>>> > What do you think is the best way forward Hugues / everyone else?
>>>>> >
>>>>> > It appears to also affect my previous installation, but due to the
>>>>> > jetty
>>>>> > temporary webapp directories being cleaned by the system (and this not
>>>>> > being
>>>>> > picked up), it was giving 404s - I think this may be a separate
>>>>> > bug/issue
>>>>> > the simple workaround being (in theory) to set Java up with a different
>>>>> > default temp file location that is not interfered with.
>>>>> >
>>>>> > Thanks for your time :)
>>>>> >
>>>>> > Matt
>>>>> >
>>>>> >
>>>>> > On Wed, Jun 27, 2012 at 10:32 PM, Jesse McConnell
>>>>> > <[hidden email]> wrote:
>>>>> >>
>>>>> >> Hugues is your best bet for an answer.
>>>>> >>
>>>>> >> --
>>>>> >> jesse mcconnell
>>>>> >> [hidden email]
>>>>> >>
>>>>> >>
>>>>> >> On Wed, Jun 27, 2012 at 4:03 PM, Matthew Painter
>>>>> >> <[hidden email]> wrote:
>>>>> >> > Hi all,
>>>>> >> >
>>>>> >> > Disclosure: This is a cross post from the users list where no-one
>>>>> >> > had
>>>>> >> > any
>>>>> >> > suggestions - I hope you as devs may have more insight? :)
>>>>> >> >
>>>>> >> > I am using Jetty7.5.1+OSGi, exposing servlets by using
>>>>> >> > Web-ContextPath.
>>>>> >> >
>>>>> >> > Say my path is Web-ContextPath is /foo and I have class bar.FooBar,
>>>>> >> > then
>>>>> >> > I
>>>>> >> > can retrieve the class file by going to:
>>>>> >> >
>>>>> >> > http://my.server/foo/bar/FooBar.class
>>>>> >> >
>>>>> >> > and I infact can list the whole directory and subdirectory by
>>>>> >> > visiting:
>>>>> >> >
>>>>> >> > http://my.server/foo
>>>>> >> >
>>>>> >> > If I have a servlet mapped to /* then this does not happen.
>>>>> >> >
>>>>> >> > This seems like an enormous issue. It hasn't happened previously,
>>>>> >> > and I
>>>>> >> > can't seem to find what has changed.
>>>>> >> >
>>>>> >> > The previous behaviour was to 404 on requesting anything but servlet
>>>>> >> > mappings, or assets that are not class files and not in META-INF or
>>>>> >> > WEB-INF.
>>>>> >> >
>>>>> >> > Can anyone shed any light on why all the class files in the bundle
>>>>> >> > are
>>>>> >> > exposed?
>>>>> >> >
>>>>> >> > Thanks!
>>>>> >> >
>>>>> >> > Matt
>>>>> >> >
>>>>> >> >
>>>>> >> > _______________________________________________
>>>>> >> > jetty-dev mailing list
>>>>> >> > [hidden email]
>>>>> >> > https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>>> >> >
>>>>> >> _______________________________________________
>>>>> >> jetty-dev mailing list
>>>>> >> [hidden email]
>>>>> >> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > jetty-dev mailing list
>>>>> > [hidden email]
>>>>> > https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>>> >
>>>>> _______________________________________________
>>>>> jetty-dev mailing list
>>>>> [hidden email]
>>>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> jetty-dev mailing list
>>> [hidden email]
>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>>
> _______________________________________________
> jetty-dev mailing list
> [hidden email]
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev