JSR-315 needs YOU for servlet 3.0

Discussions

News: JSR-315 needs YOU for servlet 3.0

  1. JSR-315 needs YOU for servlet 3.0 (28 messages)

    The expert group for JSR 315 (servlet-3.0) has come to a bit of an impasse regarding some new features for auto discovery of servlets and filters. Some members of the EG have some security/flexibility concerns regarding these features, but others do not think the concerns significant enough to warrant additional complexity in configuration options. The core issue is about new Framework Pluggability features that are proposed to allow Filters and Servlets to be deployed an configured via annotations, discovered web.xml fragments or programmatically in Listeners discovered in TLD descriptors or web.xml. Together, these features are intended to allow webtools and frameworks to be configured simply by dropping a jar into WEB-INF/lib. The current proposal gives the choice between full automatic discovery and deployment of all web features discovered in WEB-INF vs full manual configuration via web.xml (but with no mechanism to disable discovered TLD listeners from configuring new filters and servlets). The fully automatic mode will be good for developers, but some on the EG are concerned that it can represent a security issue with accidental or obfuscated deliberate deployment of unintended filters and servlets. The EG debating the pros and cons of more a more flexible approach. The impasse has been reached is that there is disagreement about how concerned the community will be about lack of control of the fully automated deployment mechanisms. Thus the EG has decided to seek more community feed back. I've blogged on the case FOR more flexibility. Hopefully others will post making the opposite case and a healthy debate will result. So now is the time for the community to voice their concerns and/or support regarding this set of features.

    Threaded Messages (28)

  2. Does anyone really care?[ Go to top ]

    Sorry if I sound negative, but how many Java developers really and truly care about the Servlet specification any more? I'd be willing to bet that 99% of Java developers don't care at all, because they are using a framework that handles all the low-level work like dealing with the Servlet API. Most of these frameworks have their own plugin architecture that works well for them, and developers are more likely to investigate that route than some way of developing Servlet Plugins. On the specific question you asked about, we've had this debate recently about how to configure all kinds of extensions to Stripes (FWIW, Stripes was probably the first framework to do completely automatic discovery of components using annotations for configuration). What we've come down to is a simple solution: have users list (in web.xml) the list of packages they'd like scanned for various things. It's simple, concise and stops random Jars loading plugins that the developer didn't know about. Back on Servlet 3.0 - is there a draft spec available somewhere yet? Is it finally going to address some important issues like an API for programmatically authenticing a user (and providing the Principal)? Or being able to use more complex globs or regular expressions for servlet mappings? Or being able to programmatically register servlet mappings at startup? -Tim Fennell Stripes: Because web development doesn't have to suck
  3. Re: Does anyone really care?[ Go to top ]

    Hi Tim, I guess you know that those frameworks you have mentioned are built based on servlet. Which means any changes to the foundation of servlet will change the frameworks. If you have automatic discovery of servlets, I would imagine that I no longer need to deal with crazy applicationContext.xml in Spring for simple servlet mapping. So do you think Java Developers should care about Servlet Specifications then? Andy
  4. Re: Does anyone really care?[ Go to top ]

    Hey Andy, Of course. All Java web frameworks are at some layer build upon Servlets. I'm the developer of a web framework, so I'm quite intimately familiar with the Servlet API. But my point is that a good framework should insulate you from the underlying servlet API because it's a very low level API. As a framework author I think there are far more important things to be addressed than what is being discussed here. I don't think the changes being talked about will really have much impact on most users, but maybe I'm missing something. -t
  5. Re: Does anyone really care?[ Go to top ]

    but some on the EG are concerned that it can represent a security issue with accidental or obfuscated deliberate deployment of unintended filters and servlets.
    Just make it so "auto-discover" is "off" by default and then if the developer/administrator turns it on, assume they have considered the implications.
  6. Re: Does anyone really care?[ Go to top ]

    or create an additional switch that forbid/allow additional deployment from a specific url/package or something like that.

    For example: allow deployment of com.example.* and disallow any other kind of additional deployment.
  7. Re: Does anyone really care?[ Go to top ]

    Back on Servlet 3.0 - is there a draft spec available somewhere yet? Is it finally going to address some important issues like an API for programmatically authenticing a user (and providing the Principal)? Or being able to use more complex globs or regular expressions for servlet mappings?
    Ditto!
    Or being able to programmatically register servlet mappings at startup?
    You'd like to think that whatever mechanism they come up with to manage and control servlets via annotation, etc. would be applied to any system able to dynamically register servlet mappings or filter mappings on the fly.
  8. Comet[ Go to top ]

    Comet should be the only thing in 3.0. Adding auto discovery will create security injection issues, when for example I use jars (that might have auto discoverable listeners). KISS, .V
  9. Re: Does anyone really care?[ Go to top ]

    Sorry if I sound negative, but how many Java developers really and truly care about the Servlet specification any more? I'd be willing to bet that 99% of Java developers don't care at all, because they are using a framework that handles all the low-level work like dealing with the Servlet API.
    Exactly! These autoconfigure features are being proposed so that frame works can further insulate developers from the details of the servlet spec. It is framework developers that will be the main authors of autoconfiguration. Web developers will just consume what they produce.

    But the question remains, should we just give total control to the framework developers or leave the OPTION of a web developer being able to have some control.

  10. I agree with the poster that said frameworks handle all the concerns regarding ease of use nowadays. All I really care about is for Java becoming a more viable solution for shared hosting environment.
  11. Security issue is bogus[ Go to top ]

    I think the security issue is bogus IMO. 1) If this is a security hole, then EJB is also one big security hole as it allows this sort of deployment. 2) If vendors think their customers will view this as a security hole, then they can solve the problem themselves by precompiling the .war file and generating a web.xml file that has some sort of "metadata complete" flag like EARs and EJBs currently have in EE 5. 3) Programmatic deployment/configuration can also be handled by the vendor implementation using the Java security model. So, IMO, this is a vendor implementation solution and this shouldn't hinder deployment flexibility in the specification. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  12. Re: Security issue is bogus[ Go to top ]

    Security is definitely not a Bogus issue and is valid concern. Once this option is available every third party library starts adding their own servlets (debugging purpose, admin purpose whatever is the reason). Opening up more than you need to (Without knowing what it can do) is always a security issue.
  13. Re: Security issue is bogus[ Go to top ]

    We can selective automatic discovery by package that can be configured. This would prevent random 3rd party jars being loaded into the web container
  14. Re: Security issue is bogus[ Go to top ]

    Bill,
    I think the security issue is bogus IMO.
    1) If this is a security hole, then EJB is also one big security hole as it allows this sort of deployment.
    The ejb security scenario is quite different to the servlet scenario. Even with automagically discovered ejbs, you would still need to arrange for them to be invoked somehow by the application's code. With automagically discovered servlets, they would be able to be invoked simply by a user surfing to a url on your site.
    2) If vendors think their customers will view this as a security hole, then they can solve the problem themselves by precompiling the .war file and generating a web.xml file that has some sort of "metadata complete" flag like EARs and EJBs currently have in EE 5.
    Unfortunately, its not as clear cut as you think. The "metdata-complete" flag is not going to stop the automatic finding and execution of Listeners which will be able to use the new api to programmatically add servlets and filters. regards Jan http://www.webtide.com
  15. Re: Security issue is bogus[ Go to top ]

    Bill,

    I think the security issue is bogus IMO.
    1) If this is a security hole, then EJB is also one big security hole as it allows this sort of deployment.


    The ejb security scenario is quite different to the servlet scenario. Even with automagically discovered ejbs, you would still need to arrange for them to be invoked somehow by the application's code. With automagically discovered servlets, they would be able to be invoked simply by a user surfing to a url on your site.

    2) If vendors think their customers will view this as a security hole, then they can solve the problem themselves by precompiling the .war file and generating a web.xml file that has some sort of "metadata complete" flag like EARs and EJBs currently have in EE 5.


    Unfortunately, its not as clear cut as you think. The "metdata-complete" flag is not going to stop the automatic finding and execution of Listeners which will be able to use the new api to programmatically add servlets and filters.


    regards
    Jan
    http://www.webtide.com
    EJBs are allowed to use timers to run on their own schedule and do what they want, breaking your security IF this were a problem. In practice, if you are deploying unknown, malicious code into your app server intentionally (which is what it would take for this to actually be a security problem) then you have bigger problems. This spec doesn't change that in the least. The fact that the servlet guys have been so slow in accepting annotations for servlet configuration is ridiculous, honestly.
  16. Re: Security issue is bogus[ Go to top ]

    In practice, if you are deploying unknown, malicious code into your app server intentionally (which is what it would take for this to actually be a security problem) then you have bigger problems.
    How many classes implement servlet in the last webapp that you deployed? Can you answer immediately? I bet not! Developers can't answer this question - NOT because they are deploying malicious code, but because they are deploying with third party jars that may contain many unused features. Those servlets don't need to be the work of an evil hacking genius in order to be a security problem. They are most probably going to be developer or debugging aids. One mans tool is anothers security hole. This is analogous to the security problems that were experienced with the invoker style, where /servlet/com.acme.SomeServlet would invoke the servlet even if it was not listed in the web.xml. These features bring back that issue, that a servlet may become available simply by being included in the WEB-INF/lib
  17. Re: Security issue is bogus[ Go to top ]

    This is analogous to the security problems that were experienced with the invoker style, where /servlet/com.acme.SomeServlet would invoke the servlet even if it was not listed in the web.xml. These features bring back that issue, that a servlet may become available simply by being included in the WEB-INF/lib
    I think the comparison with the invoker servlet to be especially bad. Mapping has to be explicit (in an annotation or a web.xml fragment), and defined in annotations. Same for listeners. In the end, it is up to the libraries to write secure code, just as before.
  18. This is analogous to the security problems that were experienced with the invoker style, where /servlet/com.acme.SomeServlet would invoke the servlet even if it was not listed in the web.xml. These features bring back that issue, that a servlet may become available simply by being included in the WEB-INF/lib


    I think the comparison with the invoker servlet to be especially bad. Mapping has to be explicit (in an annotation or a web.xml fragment), and defined in annotations. Same for listeners. In the end, it is up to the libraries to write secure code, just as before.
    I disagree. The end result is the same. Servlets exposed you don't want exposed.
  19. I disagree. The end result is the same. Servlets exposed you don't want exposed.
    This is evidently completely different. The invoker's servlet problem is that it requires nothing explicit at all (merely extends Servlet), when this one needs an explicit annotation tagging by the developer, *with a URI mapping put in explicitly* (ex: @Servlet(urlMapping={“/foo”})). This is an early draft, with things still in discussion (like adding ordering, which would also allow locking down the feature), so there's really nothing at all to scream about at this point.
  20. so there's really nothing at all to scream about at this point.
    agreed... we can scream on the eg mailing list. :-)
  21. Finally -[ Go to top ]

    Great to find that this issue is being finally talked about. I have been looking for this for almost two years. See my 2006 post making a case for this: http://www.subbu.org/weblogs/main/2006/05/need_an_spi_for.html
  22. The security issue is a valid one. Not having seen the specification, I think it can be resolved easily. Configuration happens three ways (it is sort of done this way now). 1) Configuration by Convention -- we have a taste of this with JPA, and other frameworks, where the field names implicitly match table column names by default. Follow some general guidelines, and you get "free" configuration. 2) Configuration by Annotation -- leveraging the above example, if you're not happy with the default mapping of the column, you can add an @Column annotation to override it. 3) Configuration by Property file -- again, if you like you can override the CbC and CbA modes by creating a configuration file that's explicit in what it wants. The issue is that for some reason the EG doesn't want to let the developers add an extra /damnit flag to their configuration file that tells the container "this is the way it is, ignore the CbC and CbA modes". Rather, when it finds something, it checks CbP, then CbA, then CbC, meaning you can't stop something from being configured. In fact the granularity is to the point where an aspect of the configuration for a single component can be done in all three places, and the final vision merged together to produce the final result. Finally, I think two tools would be very handy. One, is a logging setting within the container that tells the container to be very verbose during its configuration so that the developer can see exactly what is going on during startup. At a minimum when someone sees "KeyloggerServlet" show up in their logs, they're at least aware that they might have a problem. Frankly, with any CbC system, this level of logging is a requirement. I loathe fighting the black box and not knowing WTH is going on inside. But the other tool I think would be handy, and I think is actually lacking now, is one that looks that the environment as is, and creates the proper configuration file that matches that environment. So, if all someone wants to do is ensure the "KeyloggerServlet" does't get loaded, they can run the tool, generate the config file, and see where "KeyloggerServlet" is mapped and simply remove the entry, set the /damnit flag and voila, he has a safe configuration without having to become a master of the arcane configuration options and defaults. This "configuration by example" is also a great way for folks to learn more about their system, since hardly anyone reads the actual specifications where this minutea is all defined. Because, done right, the petty details only affect edge cases of common use (otherwise they should be "doing the right thing"). Negative configuration can also have its place (do everything but "this.*"), but even that is open to potential abuse, as it still lets "anything else" in. You have to specifically disable things, rather than specifically enable. Explicit enabling is "safer" IMHO. But it is counter to the CbC and CbA memes, so negative configuration would still have it's place I think, so you don't have to necessarily throw out all of the babies with the bathwater.
  23. Controlled flexibility[ Go to top ]

    That automagical mode might be interesting for lazy developers... true. BUT in order to remain acceptable in the corporate (aka Fortune 500) world it must be possible to impose strictly controlled behaviour. Those corporate security-controllers hate nothing more than software that does stuff automatically. Espescially when we consider also dynamic additions like OSGi-like stuff, it becomes a nightmare. Or servlet filters that do mutually exclusive stuff... How do you controll that filters do always execute in the same order? How can you make sure that a servlet does not "steal" the mapping of another one? Therefore even the hint that tld-stuff can still define stuff during runtime is a security risk. What if a webapp-module that I buy from a supplier (without the source) is misbehaving? Just, PLEASE, leave a possibility to disable all those automatisms and give me complete control with the one and only web.xml. LET THERE BE CHOICE!
  24. Re: Controlled flexibility[ Go to top ]

    Just, PLEASE, leave a possibility to disable all those automatisms and give me complete control with the one and only web.xml.
    LET THERE BE CHOICE!
    +++++++
  25. That automagical mode might be interesting for lazy developers... true.
    BUT in order to remain acceptable in the corporate (aka Fortune 500) world it must be possible to impose strictly controlled behaviour. Those corporate security-controllers hate nothing more than software that does stuff automatically.
    This is exactly the message I have been getting at IBM. The metadata-complete flag is currently useful for the prevention of annotation scanning, but it needs to be expanded beyond the current true or false values to allow values like "annotations-complete" or "web-fragments-complete". This, in concert with the ability to delimit which jars and classes to scan, will give those corporations the strict control that they demand. Some on the EG haven't seen these concerns.
  26. Flexibility is not needed of course[ Go to top ]

    The stability of the web.xml file is a feature which should be cherished. Heck, I would even like to have a proper JSP compiler configured as a Servlet in the web.xml, so I can clearly see how the JSP compiler is configured, if at all. Adding a framework to the Servlet configurations in web.xml adds to the understanding of the whole web application. If this configuration is determined by an automagic run over all kinds of options, I am not too sure whether comprehensibility improves: 1. If annotation available on Servlet/Filter class, use it; 2. otherwise if JAR file contains manifest - which contains an XML file - which contains a Servlet config item, use it; 3. otherwise, use web.xml configuration 4. additionally, also take care of Servlets added at runtime! Why the need for more flexibility? How did we miss this feature in the Servlet spec for the last, like, ten years? How many blog posts are devoted to this missing feature, as opposed to e.g. Asynchronous support?
  27. Stop adding useless crap[ Go to top ]

    Dear JSR-315. Please, stop adding useless crap to the spec. No one cares about autoconfiguration - most people just add one 'org.somepackage.FavoriteFrameworkServlet' to web.xml and then forget about servlets. Servlets are not 'high-level' anymore, they are the low-level foundation for other frameworks. So concentrate on LOW-LEVEL features that are NOT possible to implement in high-level frameworks. For example: make a standard API for Comet-like processing. It sorely needed for a lot of AJAX applications.
  28. These low-level features are being worked on as well.
  29. More problems..[ Go to top ]

    The main problem (IMHO) isn't that Servlet is going to introduce auto-discovery of Servlets. The main reason I don't think its a big deal is because you can turn it of using one line of XML in the web.xml. The bigger problem I don't hear much about is the use of annotations for everything. They will break a lot of programming rules doing this. Suddenly you don't have code-completion, the IDE can't see if you make a typo in a method signature etc. And why?? The fact is, I don't think there is a real reason you must annotations for this, they just like annotations maybe? The reason this new JSR was created is to provide ease in development for the programmers. But taking code-completion and IDE-typo-checking away is doing the complete opposite I think. More on this subject on my website: http://www.redcode.nl/blog16.html