RE: Security for Actions or ActionClasses?
Hmmm... So, what is the bottom line - stick to one particular servlet container? Or is it possible (and/or feasible) to implement security handling for multiple containers, say tomcat and resin? -Original Message- Subject: RE: Security for Actions or ActionClasses? Date: Thu, 29 Nov 2001 09:10:56 -0600 From: "AJ Morris" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> True, ultimately it is the container reports back the roles. The security methods are part of the JDK, such as isUserInRole(), getUserPrinciple(), etc. However, each container implements the underlying architecture differently, including the assignment of users, roles, and groups differently. For example, Tomcat offers the concept of realms -- MemoryRealm or JDBCRealm. Websphere implements this totally differently, by accessing the underlying Local Operating System registry, LDAP, or by exposing an API for custom plugins. Editorial:: Tomcat has the best security implementation I've seen, while Websphere's approach is senseless; LocalOS? What's up with that? -- Fyodor Golos ResGen, Invitrogen Corporation 2130 Memorial Pkwy, SW Huntsville, AL 35801 Phone: 800-533-4363 Direct: 256-327-4297 Fax: 256-536-9016 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Security for Actions or ActionClasses?
Nic's package looks very interesting! However, in the end it's the container that reports back which role the user is in, correct? I am still puzzled as to how to implement that part. Is it container-specific? In other words, when I implement role-based security, do I just lock myself into, say, Tomcat, and stick to it forever? That kinda hurts portability. Anyone cares to correct me? -- Fyodor Golos ResGen, Invitrogen Corporation 2130 Memorial Pkwy, SW Huntsville, AL 35801 Phone: 800-533-4363 Direct: 256-327-4297 Fax: 256-536-9016 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
purpose of reset()
Since this thread (Design question - Action Form vs Business Delegates/Value Objects) is really taking off on a different tangent I thought I'd change the subject line. Ted, I've seen this briefly mentioned here and there - about using reset() only when checkboxes are used. Can you please elaborate on this one? Shouldn't I always call reset() in case I am given a "dirty" object and it should be populated from the form from scratch? > I don't see where this part of the thread began, but reset() is always > called before the bean is autopopulated from the request, regardless of > scope. If your reset is setting fields you want to retain to null, you > should have it stop. This is really only necessary when checkboxes are > expected. > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel +1 716 737-3463 > -- http://www.husted.com/struts/ -- Fyodor Golos ResGen, Invitrogen Corporation 2130 Memorial Pkwy, SW Huntsville, AL 35801 Phone: 800-533-4363 Direct: 256-327-4297 Fax: 256-536-9016 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
ActionForms lifecycle across multiple requests
I am trying to save myself A LOT of repetitive coding by reusing my
business objects in my ActionForm objects. For example, this is how one
of them looks like:
public MyActionForm extends ActionForm {
private MyBusinessObject businessObject;
...
}
The HTML form that uses this object only represents a subset of various
properties (some indexed, some nested, i.e. all kinds). In html taglibs
I am referring to them as "businessObject.nested[0].title", etc. The
HTML form represents a subset of all of the properties, therefore after
the form is submitted, only SOME of the properties come back as request
parameters.
If I do not implement validate() and leave my form alone, can I count on
the same business object to still be there? In other words, is my form
saved in the session context or is there a pool of MyActionForm objects
used by multiple sessions and this session might get someone else's
MyActionForm?
In general, am I abusing the system, so to speak? Should I implement an
ActionForm that simply maps to my HTML form one-to-one and then perform
conversions between that object and my business objects? I just have
quite complex objects and would like to save myself time by reusing
already implemented javabeans.
Thanks!
--
Fyodor Golos
ResGen, Invitrogen Corporation
2130 Memorial Pkwy, SW
Huntsville, AL 35801
Phone: 800-533-4363
Direct: 256-327-4297
Fax: 256-536-9016
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
populating an ActionForm with indexed properties
I have an ActionForm with nested indexed propeties:
public class MyActionForm extends ActionForm {
private List nested;
...
}
where each nested element is:
public class Nested {
private String title;
private Double price;
...
}
Assume that my reset() looks like this:
public void reset(...) {
nested = new ArrayList();
}
I can display this form in a jsp (using latest html taglib, not 1.0
release) but I am stuck populating my ActionForm with submitted
parameters.
Property names, such as "nested[0].title", etc., are created just fine
in my html pages.
Obviously, struts (or actually it's commons-beanutils) does not know
that I need a list of Nested objects, although it might have an idea of
how many. Is there anything that I can implement so that my form will
get a chance to go ahead and create a list of Nested objects so that
actual indexed properties can be set?
Right now, I end up with an empty list when all is said and done... :(
The code I provided is obviously just an example I used for
generalization.
Thanks!
--
Fyodor Golos
ResGen, Invitrogen Corporation
2130 Memorial Pkwy, SW
Huntsville, AL 35801
Phone: 800-533-4363
Direct: 256-327-4297
Fax: 256-536-9016
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: inconsistency between and
John, My apologies - I did not express myself clearly in the first email. I would like to provide "GLOBAL FORWARD", not "ACTION NAME" in field. The real reason I am bringing this question up is the "Use Global Forwards for all entry points to applications" Struts pattern described by Ted Husted at http://husted.com/about/scaffolding/catalog.htm. I am trying to stick to that pattern and use only global forwards on my JSP pages. Am I on the right track? Can anyone share their preferred way of using forwards vs. actions on JSP pages and within actions themselves? >Maybe I misunderstood what you said... > >The action path specified in is already a logical >path which is defined in in the struts-config.xml. > >>According to documentation, takes either a name >>of a global forward, an arbitrary href, or a context-rooted page URL. On >>the other hand, only allows one type: a URL to >>which the form should be submitted. >> >>Is it unreasonable to expect somewhat consistent behavior between the >>two? I would love to specify a global action name as form action field. >>That way my JSP pages NEVER reference physical locations but logical >action names only. -- Fyodor Golos ResGen, Invitrogen Corporation 2130 Memorial Pkwy, SW Huntsville, AL 35801 Phone: 800-533-4363 Direct: 256-327-4297 Fax: 256-536-9016 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
inconsistency between and
According to documentation, takes either a name of a global forward, an arbitrary href, or a context-rooted page URL. On the other hand, only allows one type: a URL to which the form should be submitted. Is it unreasonable to expect somewhat consistent behavior between the two? I would love to specify a global action name as form action field. That way my JSP pages NEVER reference physical locations but logical action names only. -- Fyodor Golos ResGen, Invitrogen Corporation 2130 Memorial Pkwy, SW Huntsville, AL 35801 Phone: 800-533-4363 Direct: 256-327-4297 Fax: 256-536-9016 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
