[ANNOUNCE] Silicon Valley Web Developer JUG
FYI, After learning about JUG support as projects on java.net at JavaOne, I decided to migrate the Silicon Valley Struts User JUG to a new JUG project on java.net. The other significant change to the group is the shift to a more general focus on all J2EE web application development technologies. Of course, we will continue to have some meetings where Struts development is the focus. The new JUG project on java.net is: Silicon Valley Web Developer JUG https://sv-web-jug.dev.java.net Everyone on the old Yahoo list are already migrated to the new list. For anyone new though, it does require that you register with java.net in order to subscribe to the new list. If you would like to become a member of this JUG, you can subscribe to the mailing list here: https://sv-web-jug.dev.java.net/servlets/ProjectMailingListList When the group does have a Struts-related event coming up, I'll continue to post announcements here on the struts-user list. However, the frequency of those postings will be lower now with the broader focus of the group going forward. That's All Folks, Van Mike "Van" Riper mailto:[EMAIL PROTECTED] https://sv-web-jug.dev.java.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] 6/27 Struts User Gathering at JavaOne
Since there were no strong preferences stated in the initial responses, I made an executive decision and went with Sunday evening after the conference opening reception. We'll be gathering around 8:30pm at the Thirsty Bear less than a block from Moscone Center. The full announcement including directions can be found here: http://tinyurl.com/2mpsq RSVP requested to [EMAIL PROTECTED] with the subject "Struts User Gathering." Please RSVP by 5:00pm on Saturday, June 26th. Thanks, Mike Van Riper Silicon Valley Struts User Group http://www.baychi.org/bof/struts/ P.S. No need to RSVP again for those of you that have already done so. You are on my list for the reservation headcount. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] JavaOne Struts User Gathering
Hi Everyone, Depending upon the interest level, I'm willing to organize a social gathering at a bar or restaurant in San Francisco during the upcoming JavaOne conference. It would either be around 8:30pm on Sunday, June 27th, after the Welcome Reception ends. Or it would be around 8:00PM on Thursday, July 1st, at the very end of the conference. It would be separate from JavaOne, but, somewhere not too far from Moscone. That way, anyone attending the conference and local folks that aren't attending the conference could both participate. If this is something you would participate in, please email directly to me (no need to spam the struts-user list with count-me-in messages) at [EMAIL PROTECTED] with the subject "JavaOne Struts User Gathering." Whatever I decide upon, I'll announce it again here on the mailing list. However, your responses to me now will give me an indication of size of venue required for the gathering. I will choose between Sunday and Thursday evening based upon the preferences I get back from the people that contact me. Also, I am not that familiar with our options in the city. So, I would appreciate recommendations for local bars/restaurants that would be a good venue for this gathering. Besides being big enough for the expected number of people, I'm looking for a place with good *beer* and at least some decent food options too. Thanks, Van Mike "Van" Riper Silicon Valley Struts User Group http://www.baychi.org/bof/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Enumerating sessions
I had to do something like this and I did use the HttpSessionListener interface (requires 2.3 servlet API support in your container) as part of the solution. However, it alone is not sufficient. The callbacks for the session creation and destruction events happen so early and so late respectively that you do not have access to any session data other than the sessionID. The solution I came up with was to record logins within the webapp to a tracking table *and* store the sessionID as a field in these records. Then, you can use the sessionDestroyed() callback to check to see if there is a login record that is still active that needs to be flagged as terminated. You have to go through all these hoops because you can't rely on the user explicitly logging out. So, to update the tracking table to reliably indicate who is currently logged in you have to do this. You will hit the sessionDestroyed() callback whether they explicitly log out and you expire the session, or the session simply times out on its own because of inactivity (or as a result of closing the client-side browser window without explicitly logging out). Hope this helps, Van Mike "Van" Riper Silicon Valley Struts User Group http://www.baychi.org/bof/struts/ mailto:[EMAIL PROTECTED] > -Original Message- > From: Nick Heudecker [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 15, 2004 1:43 PM > To: Struts Users Mailing List > Subject: Re: Enumerating sessions > > > Wouldn't this do it? > > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/servletapi/jav > ax/servlet/http/HttpSessionListener.html > > Frank Zammetti wrote: > > > Hello all... is there any good way to enumerate all > sessions under a > > given webapp? I know there used to be the SessionContext, > but that has > > since been deprecated as of servlet spec 2.1 I believe... Is there > > anything in Struts that might help? > > > > Basically I'm just looking for an accurate way to display > all currently > > logged on users, and also have the ability to add a session > attribute to > > all of them (think broadcast messages and forced graceful > logoffs). I > > keep hearing the term "Session Listenter", but my research > is turning up > > server-specific (or third party-specific references), and I > need this to > > be server-nuetral. > > > > I could I guess create a wrapper class that is called to > create or kill > > a session, as well as to add of remove attributes, but I'd prefer > > something that won't require me to change a lot of code, or > any really! > > > > Thanks in advance for any ideas! > > > > Frank > > > > _ > > MSN 9 Dial-up Internet Access fights spam and pop-ups – now > 3 months > > FREE! http://join.msn.click-url.com/go/onm00200361ave/direct/01/ > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- > Nick Heudecker > System Mobile, Inc. > Email: [EMAIL PROTECTED] > Web: http://www.systemmobile.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Validator mask boundary matchers don't work
> > > > I'll try your suggestion. > > > I tried \w+\s\w+ (plus instead of * in order to require at > least one), > and it still accepts more than two strings, e.g. "xxx yyy zzz"... Are you including the special start of line "^" and end of line "$" characters in your regular expression. Unless you do, it will match the first occurrence of two words in the text rather than require that there be exactly two words in the text. In fact, I assume you don't mind if there is leading or trailing spaces (or even additional spaces between first and second word). So, I think you want: ^\s*\w+\s+\w+\s*$ This will require exactly two words with optional leading/trailing spaces and even allow for more than one space between the two required words. -Van - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dealing with XSS in struts
> -Original Message- > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 05, 2004 11:01 AM > To: Struts Users Mailing List > Subject: Re: Dealing with XSS in struts > > > Van Riper, Mike wrote: > > >>-Original Message- > >>From: Craig McClanahan [mailto:[EMAIL PROTECTED] > >>Sent: Wednesday, May 05, 2004 9:47 AM > >>To: Struts Users Mailing List > >>Subject: Re: Dealing with XSS in struts > >> > >> > >>jeff mutonho wrote: > >> > >> > >> > >>>Hi > >>>What are the recommendations to deal with cross-site > >>> > >>> > >>scripting in struts? > >> > >> > >>>I'm got an app that a use can access at a URL , let's call > >>> > >>> > >>it http://localhost/myapplication , now doing something like > >> > >> > >>>http://localhost/myapplication/applicationInit.do?mode= >>> > >>> > >>t>alert(document.cookie) > >> > >> > >>>reveals a pop-up box containing the currently set cookies. > >>> > >>>How can I block that from happening?Is there a way of > >>> > >>> > >>encoding a form bean?Please help as this is critical to the app. > >> > >> > >>> > >>> > >>> > >>> > >>One of the keys to avoiding the particular XSS attack you > are talking > >>about here is to be careful about how you render dynamic > content that > >>was originally entered by the user. For example, if your > >>string above > >>was read in to a bean property named "mode" and you wanted to > >>render it > >>as text in another page, you should use something like: > >> > >> > >> > >>instead of something like: > >> > >> <%= mybean.getMode() %> > >> > >>Struts protects you because (unless you explicitly ask it > not to), it > >>will render "<" as "<" so that the embedded script will > >>not actually > >>get executed. Using the runtime expression, or things like > >>that, simply > >>copy the bytes back out again with no filtering. > >> > >> > > > >However, this only protects you when you are diligent in all your JSP > >coding. My management was more comfortable with an approach > (see my other > >recent posting on this same topic) that didn't rely on that > being true. > > > > > Did you implement an escaping mechanism for cases where you > legitimately > needed a "<" character in the input data? If so, you might > still be at > risk even with a filter, unless you are diligent as well. We live with the limitation that input data can't contain special characters like "<". In the rare cases where we absolutely need it, we use our own convention for escaping the input data and then unescaping it server-side. > Side note -- using a servlet request wrapper on a 2.2 > container, in the > manner you did it, is playing with fire since the servlet > spec (2.2) had > explicit assumptions that the request and response objects > passed around > were the original ones on the request. That's why we had to play the > strange games on file uploads in a 2.2 world, ensuring that > we unwrapped > the request before trying to use a request dispatcher. Thanks for the warning. I do remember seeing a problem a long time ago in the first iteration of my solution on 2.2. At present, all our Struts webapps that use it are running in a container that supports 2.3. So, that is no longer an issue for us. > >Maybe that says something about what they think of me? :-) > > > > > > :-) > > Craig Van - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dealing with XSS in struts
> -Original Message- > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 05, 2004 9:47 AM > To: Struts Users Mailing List > Subject: Re: Dealing with XSS in struts > > > jeff mutonho wrote: > > >Hi > >What are the recommendations to deal with cross-site > scripting in struts? > >I'm got an app that a use can access at a URL , let's call > it http://localhost/myapplication , now doing something like > > > >http://localhost/myapplication/applicationInit.do?mode= t>alert(document.cookie) > >reveals a pop-up box containing the currently set cookies. > > > >How can I block that from happening?Is there a way of > encoding a form bean?Please help as this is critical to the app. > > > > > > > One of the keys to avoiding the particular XSS attack you are talking > about here is to be careful about how you render dynamic content that > was originally entered by the user. For example, if your > string above > was read in to a bean property named "mode" and you wanted to > render it > as text in another page, you should use something like: > > > > instead of something like: > > <%= mybean.getMode() %> > > Struts protects you because (unless you explicitly ask it not to), it > will render "<" as "<" so that the embedded script will > not actually > get executed. Using the runtime expression, or things like > that, simply > copy the bytes back out again with no filtering. However, this only protects you when you are diligent in all your JSP coding. My management was more comfortable with an approach (see my other recent posting on this same topic) that didn't rely on that being true. Maybe that says something about what they think of me? :-) > > > >jeff mutonho > > > > > > > Craig Van - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dealing with XSS in struts
Jeff, The way that I solved this was to implement my own subclass of the TilesRequestProcessor (because we use Tiles) and then specify that request processor in the controller element of the struts config file. In this subclass, I override processValidate() and in my override I wrap the incoming request object with my own extension of HttpServletRequestWrapper (part of 2.3 Servlet API, but, you could just pull that class into your project to make this work with a servlet container that only supports the 2.2 version of the Servlet API). My extension of the request wrapper class has both a helper function to do validation of the request parameters for XSS *and* filtering on the parameter getter functions to prevent a round-trip back to the client of any nasty XSS stuff. This allows me to do the XSS check in one bottleneck and treat it as a form validation error when XSS request parameter data is detected. If the XSS validation check passes, then I call the super.processValidate() and let Struts take it form there. I suppose something similar could be done using a request filter, but, I like doing it inside the request processor where I have access to the associated Struts action mapping along with the request object. With the action mapping available to me, I can do logical forwarding using struts configuration settings in this context that I wouldn't be able to do with a separate request filter. I've used this technique successfully on several projects. In one project, the paradigm was to take the user back to the input page with an error message at the top and cleaned up data redisplayed in the form. In another project, they preferred to go to a separate error page specific to XSS errors. With this approach, I was able to implement the first way relying on the "input" setting of the associated action mapping. I was also able to implement the second approach using a global forward for the error page and doing a lookup (i.e., mapping.findForward()) to implement the error handling that way. Hope this helps, Van Mike "Van" Riper Silicon Valley Struts User Group http://www.baychi.org/bof/struts/ > -Original Message- > From: jeff mutonho [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 05, 2004 4:52 AM > To: [EMAIL PROTECTED] > Subject: Dealing with XSS in struts > > > Hi > What are the recommendations to deal with cross-site > scripting in struts? > I'm got an app that a use can access at a URL , let's call > it http://localhost/myapplication , now doing something like > > http://localhost/myapplication/applicationInit.do?mode= alert(document.cookie) > reveals a pop-up box containing the currently set cookies. > > How can I block that from happening?Is there a way of encoding a form bean? > Please help as this is critical to the app. > > jeff mutonho - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] 5/5 Vic Cekvenich talk at Silicon Valley Struts User G roup Mtg
The next meeting of the Silicon Valley Struts User Group will be a presentation by Vic Cekvenich on BasicPortal and Rich User Interfaces for the Web. The meeting will be at VeriSign in Mountain View on the evening of May 5th, 2004. The full meeting announcement including directions can be found here: http://www.baychi.org/bof/struts/20040505/ If you plan on attending, an RSVP in advance is requested. Please send RSVPs to me no later than noon on the day of the meeting. Thanks, Van Mike "Van" Riper mailto:[EMAIL PROTECTED] Silicon Valley Struts User Group http://www.baychi.org/bof/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
