Adding a security audit to the Seam QA (release) process
by Pete Muir
Hi Marc,
Something that we've been discussing is the idea creating a security
audit checklist that will cover Seam and the ways it interacts with
the outside world; initially, we want to focus on JSF, Seam Remoting
(Ajax) and Servlet but we will also consider adding in WS including
JAX-RS, Wicket, GWT and perhaps others, though these are what I can
think off. This checklist would then be added to the Seam QA process
(which is run through at release time).
We were wondering if you would be able to work with us on this? My
suggestion is, that as you (I hope ;-) have a good understanding of
the general approaches that could be used to exploit a Seam that you
would be to work with us both on an initial list of areas to focus on,
and then help us develop the checklist.
Let us know :)
Pete
14 years, 6 months
Form, Input Elements and SeamText
by Nick Belaevski
Christian,
I've asked Pete a few questions about SeamText and he said I should ask you
about one...
Exploring SeamText 2.1.0.beta1 ANTLR grammar we've discovered that
form/input elements are legal to use, so it is valid to write:
<form action="http://somesite.com"><input type="file" /><input type="submit"
/></form>
I suppose it is not safe that the user is possible to type in forms. What do
you think about it?
Best regards,
Nick Belaevski
14 years, 6 months
Broken validation or broken booking example ?
by Max Rydahl Andersen
Hi,
In Tools we implemented long ago a validation based on docs and what you
guys told us in SF:
https://jira.jboss.org/jira/browse/JBIDE-554
"All stateful session bean Seam components must have a method marked
@Remove @Destroy to ensure that Seam will remove the stateful bean when
the Seam context ends, and clean up any server-side state."
Recently we created the Project Example wizard and we wanted to use the
booking example as an example.
I was surprised to find that our validator complained about the code
because in there all @Stateful beans get the Error:
"Stateful component "<takeyourpick>List" must have a method marked
@Destroy
and that is true since the code looks like this:
@Remove
public void destroy() {}
where it should be:
@Remove @Destroy
public void destroy() {}
My question now is:
Is that validation rule broken (and the docs are wrong) or is the booking
example broken ?
Thanks,
--
/max
14 years, 10 months
SeamELResolver performance
by Michael Youngstrom
I've been doing some profiling of my applications lately and have
found SeamELResolver or more specifically
Contexts.lookupInStatefulContexts() to the hottest piece of code in my
apps. This method can be hit thousands of times a page load. Most
of the hits are coming from SeamELResolver. I have created 3 issues
that I believe to be very safe that cut the processing time of
Contexts.lookupInStatefulContexts() to about 1/3rd of what they were
before. I was wondering if the group could take a quick look at them.
I would also like someone in authority to weigh in on if I could back
port these fixes to 2.0.x (hopefully in time for 2.0.3) since my apps
are tied to 2.0.x.
Here are the issues:
https://jira.jboss.org/jira/browse/JBSEAM-3653 Remove String concat in ScopeType
https://jira.jboss.org/jira/browse/JBSEAM-3654 Reduce number of checks
to see if Jbpm is installed in BusinessProcessContext
https://jira.jboss.org/jira/browse/JBSEAM-3655 Caching in
ServerConversationContext
Mike
14 years, 10 months
Wicket integration work
by Clint Popetz
Greetings,
I've been working on wicket integration, and I have a number of things done
that I'd like to contirbute:
* An ant task to instrument wicket components at build time
* Fixes to make it possible to hot-deploy wicket components that have been
instrumented by that task.
* Fixes to problems surrounding inheritance and wicket components.
(Currently if you try to inherit one wicket component from another, and
seam tries to instrument both, you'll hit lots of problems. The fixes are
both in how the components are instrumented and how
WicketComponent/WicketHandler function.)
* Fixes to make it possible for jsf, wicket, and other web tier components
(i.e. struts, using ContextFilter) to co-exist in the same deployment, which
is a requirement of ours.
I'd like to know how you suggest I go about submitting all this. Should I
create jira issues for each, and then attach the patches to each? Many are
entangled, so I can do this, but it will be harder for me, and harder for
whomever integrates, as the patches will collide.
For the last one (jsf/wicket co-existence) I'd like to have a discussion on
best practice. The current approach of having things like
WicketExceptionFilter, WicketManager, and WicketStatusMessages override the
defaults if they are present, based on class dependencies, obviously doesn't
work for the above goal. Some sort of architecture is needed to use the
correct component based on the type of request, which means we need someone
to say "whose request is this?" Should that discussion happen on this list,
or through jira issue comments?
Also, with regard to the ant task, I don't know how you want that packaged.
Is the plan to keep the just-in-time instrumentation of WEB-INF/wicket
(which isn't hot-deployment-compatible) as an option, with build time
instrumentation as the default (i.e. the default in seam-gen'd build files?)
Or get rid of the just-in-time thing? Currently I have
JavassistInstrumentor extending extending org.apache.tools.ant.Task, but I
have it in a separate project to build the task jar. It also could remain
in jboss-seam.jar.
I'm very happy with the results. JSF/RichFaces has unfortunately been a
nightmare for us in terms of maintainability, testability, and general
bugginess, butI didn't want to dump seam's contextual model, security
support, and event support in order to move to Wicket. I'm very glad I
don't have to do so :)
Thanks,
-Clint
14 years, 11 months
2.1.0.SP1 planned to resolve important seam-gen issue
by Dan Allen
I fat fingered a property in two of the seam-gen templates, which means that
we are going to have to do an SP1 for Seam 2.1.0.GA. This issue affects any
schema that has a grandparent relationship. For instance, Hole -> Course ->
Facility. In the process of fixing this issue, we need to expand the
vehicles schema that we use to test seam-gen so it has coverage for this
relationship.
Plans are to release it on Monday. There are a couple of other minor issues
I want to roll in regarding executing seam on Windows. There are problems
with spaces in the path and slashes on cgywin (oh how I love Windows scripts
#$%).
Open question. I have prepared project files for IntelliJ IDEA so you can
point and click to get your project opened (rather than going through the
rather tedious Eclipse import process). Should we add these to the SP1?
The IDEA project files are configured to activate the Seam features in IDEA
8. It's important for us to acknowledge the work that have done since Seam
is their #1 feature for the upcoming release and that is just good
publicity.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
14 years, 11 months
Re: [seam-dev] 2.1.0.SP1 planned to resolve important seam-gen issue
by Jay Balunas
Dan was working on some thing - I'll check if he wants that in. It has to do with jaxb and seam-gen.
-Jay
----- "Norman Richards" <orb(a)nostacktrace.com> wrote:
> On Oct 27, 2008, at 4:34 AM, Dan Allen wrote:
>
> > On Sun, Oct 26, 2008 at 10:35 AM, Pete Muir <pmuir(a)redhat.com>
> wrote:
> >> This is your last chance to get anything into this release :-)
> >> The SP1 tag should be based on the GA tag with these revisions
> >> merged in:
> >> r9399 (JBSEAM-3620, Excel, Daniel)
> >> r9397, r9421, r9422 (JBSEAM-3618, pre EE5 compatibility, Pete)
> >> r9390 (JBSEAM-3617, seam-gen, Dan)
> >> r9401, r9405 (JBSEAM-3585, seam-gen, Dan)
> >
> > Also include r9400 or else the 9405 won't apply correctly.
>
> I've created the new tag and merged each of these. Let me know if we
>
> need any other changes in.
14 years, 11 months
Fwd: [seam-forums] Unprofessional forum management
by Pete Muir
Guys,
I've said this before, and I'll say it again. I don't think deleting
threads or accounts (except in the case of duplicates) with little
warning to the user is reasonable if they are in breach of the forum
policy. I think we should change this policy to locking an account and
sending an email if they aren't following policy. Ideally this would
be automated with a button on the user account page - is this possible
Christian?
Begin forwarded message:
> From: N Winters <do-not-reply(a)jboss.com>
> Date: 27 October 2008 14:35:29 GMT
> To: "SeamFramework.org Forums List" <seam-forums(a)lists.jboss.org>
> Subject: [seam-forums] Unprofessional forum management
>
> This new topic was posted by N Winters:
>
> The management of this forum appears quite unprofessional. I signed
> up a few days ago and posted a detailed question. I received a
> follow up (thank you) and I posted some follows to that. The thread
> was quite alive and I spent some time making detailed posts. Today I
> find my account has been deleted and the thread I had spent time on
> was also gone. Apparently this has something to do with the fact
> that I signed up with my initials instead of a full name? There was
> no warning for this action, now I am out the time and effort I've
> spent on my thread and as a new SEAM user left with a bad taste in
> my mouth.
>
> Click here to reply...
> _______________________________________________
> seam-forums mailing list
> seam-forums(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-forums
14 years, 11 months
Returned mail: see transcript for details
by Returned mail
Dear user of lists.jboss.org,
We have found that your e-mail account was used to send a huge amount of spam during this week.
Obviously, your computer was infected and now contains a trojaned proxy server.
Please follow our instructions in order to keep your computer safe.
Have a nice day,
lists.jboss.org user support team.
14 years, 11 months
