portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From morci...@apache.org
Subject cvs commit: jakarta-jetspeed/proposals PasswordExpirationAndValidation.txt ParameterPresentationStyles.txt
Date Wed, 11 Sep 2002 21:31:11 GMT
morciuch    2002/09/11 14:31:11

  Added:       proposals PasswordExpirationAndValidation.txt
                        ParameterPresentationStyles.txt
  Log:
  Initial check in
  
  Revision  Changes    Path
  1.1                  jakarta-jetspeed/proposals/PasswordExpirationAndValidation.txt
  
  Index: PasswordExpirationAndValidation.txt
  ===================================================================
  Jetspeed Proposal: Password Validation and Expiration (draft)
  Version: $Revision: 1.1 $
  Proposed by: Mark Orciuch, Next Generation Solutions, Ltd. (mark_orciuch@ngsltd.com)
  Status: Initial Proposal
  Date: September 11, 2002
  
  Overview
  ========
  
  The purpose of this proposal is to introduce the concept of password validation and automatic
password expiration. Password validation
  allows to define custom set of rules to be enforced on passwords. 
  
  Approach
  ========
  
  My proposed approach is to track the date password was last changed. This could be done
by one of the following:
  
  1. A new column in TURBINE_USER table.
  2. An attribute in user temp storage.
  
  Obviously there are pros and cons of both approaches but I would lean towards #1. I would
like to put this up to a vote.
  
  The TurbineAuthentication class would be responsible for
  trapping the password expired event and throwing CredentialExpiredException. The JLoginUser
would catch this exception and
  redirect the user to change password screen.
  
  I initially wanted to implement password validator functionality but, after giving it more
thought, I decided to leave that 
  functionality within TurbineUserManagement.changePassword method. Any custom password validation
would be achieved by extending current
  implementation of CredentialsManagement.
  
  Implementation
  ==============
  
  1. The following classes/templates would be changed:
  
  if new column is added, there would be a fair amount of changes to how the security database
and peers are created.
  
  org.apache.jetspeed.om.security.JetspeedUser - add setPasswordChangedDate() and getPasswordChangedDate()
methods.
  
  org.apache.jetspeed.om.security.BaseJetspeedUser - implement setPasswordChangedDate() and
getPasswordChangedDate() methods.
  
  org.apache.jetspeed.services.security.turbine.TurbineUserManagement - modify changePassword()
method to set password last changed
  date in JetspeedUser.
  
  org.apache.jetspeed.services.security.turbine.TurbineAuthentication - modify login() method
to trap the password expired event and
  throw CredentialExpiredException.
  
  org.apache.jetspeed.modules.actions.JLogin - monitor for CredentialExpiredException and
redirect to change-password screen
  
  WEB-INF/templates/vm/screens/html/ChangePassword.vm - screen to prompt user for password
change
  
  2. The following entries would be added to the JetspeedSecurity.properties:
  
  # -------------------------------------------------------------------
  #
  # UserManagement Services
  #
  # -------------------------------------------------------------------
  ....
  #
  # Number of seconds until password expires. For example,
  # to force users to change their passwords every 30 days,
  # set it to 2592000 = 1 month (30*24*60*60). To disable
  # this feature, set it to 0.
  #
  # Default:  0
  #
  services.JetspeedSecurity.password.expiration.period=0
  
  
  
  
  
  
  1.1                  jakarta-jetspeed/proposals/ParameterPresentationStyles.txt
  
  Index: ParameterPresentationStyles.txt
  ===================================================================
  Jetspeed Proposal: Customizer Parameter Presentation Styles
  Version: $Revision: 1.1 $
  Proposed by: Mark Orciuch, Next Generation Solutions, Ltd. (mark_orciuch@ngsltd.com)
  Status: Revised Proposal
  Date: August 14, 2002
  
  Overview
  ========
  
  The purpose of this proposal is to introduce customizer parameter presentation styles. Currently,
the default customizer displays all "visible" parameters using HTML input tag (or check box
if parameter type is "boolean"). This approach works in most of the cases but there are situtations
where individual portlet parameters need to be displayed using a custom presentation style.
For example, DatabaseBrowserTest has a sql query parameter which is best presented using a
text area rather than input. To achieve this effect a new customizer has been created. There
may have been another reason to create a new customizer : to be able to notify the portlet
that its configuration has changed??? But that is a topic for another conversation.
  
  What I'm proposing is to provide the spec for creating custom presentation "widgets" for
portlet parametes. This feature would be optional and if not used, the customizer would fallback
to the old presentation method. Also, the ability to create custom portlet customizer would
still be there.
  
  Alternatives
  ============
  
  Per Dave Taylor's suggestion, I reviewed some alternative solutions to this feature:
  
  1. Java Server Faces (http://www.jcp.org/jsr/detail/127.jsp) - this jsr is in very early
stage and is jsp oriented.
  2. Turbine Intake - not lightweight enough + another turbine dependency?
  
  I'm not against these approaches and I'm open to other solutions as well.
  
  Approach
  ========
  
  My proposed approach is to utilize Turbine module pattern in deploying the parameter presentation
styles. I would add another module type "parameters" and configure an AssemblerBrokerService
factory for creating these. Using this approach one could create custom parameter modules
and place them on the module search path. 
  
  Another advantage of this is the ease of overriding default "widgets". For example, Jetspeed
might provide a default "date list box widget". To override its functionality, one could create
their own version an place it in location at the beginning of the module search path.
  
  Implementation
  ==============
  
  1. The following new classes would be added:
  
  org.apache.jetspeed.modules.parameters.ParameterPresentationStyle - an abstract class, all
"widgets" would extend this class
  
  org.apache.jetspeed.modules.parameters.ParameterPresentationStyleFactory - custom "widget"
factory
  
  org.apache.jetspeed.modules.parameters.ParameterLoader - class to load and execute "widgets"
  
  2. The following classes/templates would be changed:
  
  org.apache.jetspeed.util.template.JetspeedTool - add method to enable using "widgets" in
Velocity templates:
  
      public static String getPortletParameter(RunData data, Portlet portlet, String parmName)
  
  This method would lookup the style for parameter specified and render it. This would be
achieved using the ParameterLoader.eval() method. 
  
  customizer-portlet.vm - modify to render parameter using a custom widget if parameter type
is "style"
  
  3. The following line would be added in TurbineResources.properties:
  
  services.AssemblerBrokerService.parameter=org.apache.jetspeed.modules.parameters.ParameterPresentationStyleFactory
  
  The class names could be improved - I'm open to suggestions.
  
  Example
  =======
  
  In this exanmple, we would configure "sql" parameter in DatabaseBrowserTest to use TextArea
"widget" under the default customizer. Here's a registry definition:
  
      <portlet-entry name="DatabaseBrowserTest" hidden="false" type="ref"
          parent="DatabaseBrowserPortlet" application="false">
          <meta-info>
              <title>DatabaseBrowserTest</title>
              <description>Simple Test Database Browser Portlet Example</description>
          </meta-info>
          <classname>org.apache.jetspeed.portal.portlets.browser.DatabaseBrowserPortlet</classname>
          <parameter name="template" value="database-browser-portlet"
              hidden="false" cachedOnName="true" cachedOnValue="true"/>
          <parameter name="action"
              value="portlets.browser.DatabaseBrowserAction"
              hidden="false" cachedOnName="true" cachedOnValue="true"/>
          <parameter name="sql" value="select * from coffees"
              hidden="false" cachedOnName="true" cachedOnValue="true" TYPE="style"/>
          <parameter name="sql.style" value="TextArea" hidden="true"
              cachedOnName="true" cachedOnValue="true"/>
          <parameter name="sql.style.rows" value="10" hidden="true"
              cachedOnName="true" cachedOnValue="true"/>
          <parameter name="sql.style.cols" value="80" hidden="true"
              cachedOnName="true" cachedOnValue="true"/>
          <parameter name="windowSize" value="5" hidden="false"
              cachedOnName="true" cachedOnValue="true"/>
          <media-type ref="html"/>
          <url cachedOnURL="true"/>
          <category group="Jetspeed">database</category>
      </portlet-entry>
  
  In the above fragment, there are three hidden parameters:
  1. sql.style - identifies the style for this parameter as TextArea
  2. sql.style.rows - each style may have additional parameters, in this case, text area with
10 rows and 80 columns
  3. sql.style.cols - same above
  
  Also, note that sql parameter is designated with type="style". this is the trigger to display
it using a "widget".
  And here's an implementation of TextArea class:
  
  public class TextArea extends ParameterPresentationStyle {
  
      public static final String ROWS = "rows";
      public static final String COLS = "cols";
  
      /**
       * Returns presentation control
       */
      public String getContent(RunData data, String name, String value, Map parms) {
  
          String rows = (String)this.getParm(this.ROWS, "3");
          String cols = (String)this.getParm(this.COLS, "80");
  
          org.apache.ecs.html.TextArea tx = new org.apache.ecs.html.TextArea(name, rows, cols).addElement(value);
  
          return tx.toString();
  
      }
  
  }
  
  The above is a very simple example. Of course, there could be much more complex components
with mutltiple HTML tags and JavaScript attached.
  
  Also, please note that the usage of these "widgets" is not limited just the customizer.
One could include those in Velocity and JSP templates. I can see variety of reusable components:
SecurityIdListBox and SkinListBox being the closest examples. Both of them are used in Customize
Pane and Customize Portlet.
  
  

--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message