I may be way off base but as a newbie, I am trying to get my head around
the general problem of how to customize a Jetspeed portal to meet my
needs while at the same time , staying in a position to move to the
next version of Jetspeed.
Every Jetspeed resource that my developers touch will have to be
remembered so that we can merge our modifications into the next version
of Jetspeed.
If I skip a version of Jetspeed (ie ignore 2.1.3 and probably 2.2 since
it is just packaging), it may be difficult to find all of the things
that have to be changed to get my customizations working again under 2.2.2.
I am wondering how everyone else deals with this. Is there a set of
"Best Practices" for developing with Jetspeed, that is becoming clear to
the Jetspeed community?
Does everyone move to the new versions as they are issued?
Ron
Ate Douma wrote:
Ron Wheeler wrote:
I think that we are faced with the same problem (or a similar one).
I am wondering if this approach will make it more difficult to
upgrade to later versions of Jetspeed since we would have radically
altered a core part of Jetspeed and might have a hard time finding
out places where the new Jetspeed version would require changes
during the upgrade.
Ron,
It is unclear to me what approach you're referring to here and which
"radical" alteration of a core part of Jetspeed you mean.
The solution which Saurabh seems to have chosen (delegating the
encryption to first time usage by setting isEncoded = 0 when creating
the credential)
is/should be a solid/stable one and uses features from Jetspeed which
will not be "altered" or "removed" any time soon.
Or, if an enhancement for these features would be provided, the
current behavior will still be possible/remain supported.
But maybe I'm missing the point/type of your approach here.
Regards,
Ate
Another approach that I am considering is to add a custom table to
hold the extra user information that I need and to keep the login,
change password, etc. functions from Jetspeed unchanged. The
username would be the key into my table and I would only need to add
a way to create the entry in the new table when a user is created and
to do any cleanup required if a user is detsroyed.
Does anyone have any sense of what the "Best Practice" is for
handling application specific user information?
Are there hooks in Jetspeed's registration flow where this
information can be created?
Ron
Dennis Dam wrote:
Hi Saurabh,
tracing it down in the code, I found the default password encoder in
the Jetspeed spring assembly configuration:
<bean id="org.apache.jetspeed.security.spi.CredentialPasswordEncoder"
class="org.apache.jetspeed.security.spi.impl.MessageDigestCredentialPasswordEncoder">
<constructor-arg
index="0"><value>SHA-1</value></constructor-arg> </bean>
this encoder class (MessageDigestCredentialPasswordEncoder) uses
SHA-1 encryption, and then applies Base64 encoding to get a valid
string.
Hope this helps ?
regards,
Dennis
$aurabh Vig wrote:
Hi,
I need to create a new portlet for User Registration as I need to
change the
User Info fields associated with each user.
I plan to create a new portlet that will create the user in the
Jetspeed
tables and add the user info fields as required by my application.
To do this I will need the password encryption being used by
Jetspeed, so
that I an create the user in SECURITY_PRINCIPAL table, its password in
SECURITY_CREDENTIALS table and the rest user info in my tables.
Thus the user created would be a jetspeed user created by my
portlet, and
thus the user would login to jetspeed only.
Could anyone please hint me on how can i use the jetspeed
encryption algo in
my portlet.
Its urgent, I m bound by a very tight schedule. Any help on that
would be
really helpful.
Regards,
Saurabh
On Nov 16, 2007 6:43 AM, $aurabh Vig <[EMAIL PROTECTED]> wrote:
Thanks Jennifer,
Could just figure that out yesterday with some hit and trials, and was
trying to see if there was some way with the admin portals to do that
automatically when a new user is created.
I guess writing a new user creation portlet is a way. anything
better than
that??
Regards,
Saurabh
On Nov 15, 2007 9:38 PM, Ford, Jennifer M.
<[EMAIL PROTECTED]> wrote:
Yes, if you make a directory for the user under pages/_user and add a
copy of the page to that, they can modify the page as much as they
want
and it won't affect any other users of your portal.
-----Original Message-----
From: $aurabh Vig [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 14, 2007 9:45 PM
To: Jetspeed Users List
Subject: Custom pages for users
Hi,
Is it possible to have the same page on any site/subsite customized
diffrerently for different users?
I mean each user gets a different view on the same page by editing the
page himself, something like igoogle.
Regards,
Saurabh
------------------------------
---------------------------------------
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
