Hi Georg,
I tried to subclass the user, but I wasn't getting anywhere trying to do
that. When I inspected the user manager, the delegate was still
referencing the default TurbineUser om and refused to accept my new
class as a substitute when I defined it in TR.props but I don't think I
tried overriding in the componentConfiguration.xml since I read the
comments that said it wasn't working.
Anyway - I like actually keeping the user class very simple and will use
the one provided. My work around to place a CustomUser object in the
user's temp space is working nicely, and even if I were to switch out
the authentication mechanism, this way I keep a reference object in the
database that won't break if a user model is changed out down the road.
I also don't have to worry about having to get rid of user history when
removing a user this way either, as the system needs to preserve all
transactions even if an employee leaves, so this way it is easier to
clean up the security object and still maintain all the data in the
background.
Thanks for the pointer to the Wiki though. If I see anything else
during the migration, I will make a note of it. Once I get everything
working, I may go back and see if I can get the old ExtendedUser stuff
working and write up something on how to do it.
--
Jeff
On 11/16/2017 05:51 AM, Georg Kallidis wrote:
Hi Jeff,
I could think of that you may use a wrapper class to access your custom fields
as explained in
https://wiki.apache.org/turbine/Turbine4/Turbine4.0M1/Diff ("How to handle extra
columns in Turbine user table with Fulcrum Security", T U R B I N E 4.0).
- The wrapper class (set services.SecurityService.wrapper.class in
TR.properties) may just need to extend o.a.t.om.security.DefaultUserImpl. You
then should have access to your custom fields there (check that TurbineUser
class is correctly defined in userManager/className in
componentConfiguration.xml). If you need custom initialization you might
override the DefaultUserImpl(TurbineUser user) constructor.
Does it work like this?
Best regards, Georg
-----Jeffery Painter <[email protected]> schrieb: -----
An: [email protected]
Von: Jeffery Painter <[email protected]>
Datum: 14.11.2017 19:36
Betreff: Re: Turbine 4.0 extended user howto
Answering for benefit of others.
I saw in the comments for componentConfiguration.xml the following lines
which I take to mean that implementing a custom extended user under
Turbine 4.0 is not an option.
<!--
Custom Turbine ORM Torque classes could not yet be used:
- requires Torque 4.1 or if using Torque 4.0 reqires manually
adding the interfaces in T-classes
- requires attribute baseClass in fulcrum-turbine-schema.xml table
elements set to appropriate
org.apache.fulcrum.security.model.turbine.entity interfaces
- requires attribute peerClass in fulcrum-turbine-schema.xml table
elements set to org.apache.fulcrum.security.torque.peer.TorqueTurbinePeer
-->
I ended up creating an object in my application schema called something
like "CustomUser" table that I have used to replace references to my old
extended user in the foreign key of those tables that needed them, and
created a USER_ID in this CustomUser table that I manually map from a
new user entry when it is recorded in the TURBINE_USER table.
Upon user login, I look up the corresponding CustomUser object and stick
that in my TurbineUser's temp storage so it is available throughout
their session while logged in, and then I can still link actions and
events in the database to the CustomUser object rather than the old
ExtendedUser.
Not a perfect solution, but it is working and seems to keep me in line
with the new fulcrum security. If you have any better recommendations,
please let me know!
Thanks,
Jeff
On 11/13/2017 03:47 PM, Jeffery Painter wrote:
Hi guys,
I am posting this here to capture any response on the mail archives.
I know that the security management has been moved to the
fulcrum-security service for Turbine 4.0 and I am digging deep into
learning how this works versus the old way in Turbine 2.3.x
Georg or Thomas, do you have any advice on how to migrate my extended
user classes to continue to work in Turbine 4.0? I only have a few
additional fields, but I really depend heavily on linking the primary
key from my custom user table into other tables within my Turbine
application.
If it is possible to do the foreign key maps for the default
TURBINE_USER in an easy way, I would be happy to just create an
additional table to store all the old "extended info" but I like the
way torque handles the foreign key enforcement.
Here is an example of my app's customer user and a logging table for
transactions. How would I do this now using Turbine 4.0? Thanks for
any advice or pointers to where this might already be documented.
I was used to doing the following and it worked nicely through turbine
2.3.3.
ExtendedUser eu = (ExtendedUser) data.getUser();
MyappUser user = (MyappUser) eu.getPersistentObj();
// Log the event
EventLog eLog = new EventLog();
eLog.setMyappUser(user);
eLog.setTransactionType(25);
eLog.setMessage("Updated vendor access to file");
eLog.setTxDate(new Date());
eLog.setNew(true);
eLog.save();
In my torque application schema XML I had....
<!-- extend the base user -->
<table name="MYAPP_USER" idMethod="native">
<!-- default turbine/torque user fields :: DO NOT CHANGE -->
<column name="USER_ID" required="true" primaryKey="true"
type="INTEGER"/>
<column name="LOGIN_NAME" required="true" size="64" type="VARCHAR"
javaName="UserName"/>
<column name="PASSWORD_VALUE" required="true" size="64"
type="VARCHAR" javaName="Password"/>
<column name="FIRST_NAME" required="true" size="64" type="VARCHAR"/>
<column name="LAST_NAME" required="true" size="64" type="VARCHAR"/>
<column name="EMAIL" size="64" type="VARCHAR"/>
<column name="PHONE" size="64" type="VARCHAR"/>
<column name="CONFIRM_VALUE" size="128" type="VARCHAR"
javaName="Confirmed"/>
<column name="MODIFIED" type="TIMESTAMP" javaName="ModifiedDate"/>
<column name="CREATED" type="TIMESTAMP" javaName="CreateDate"/>
<column name="LAST_LOGIN" type="TIMESTAMP"/>
<column name="OBJECTDATA" type="VARBINARY"/>
<!-- custom fields -->
<column name="VENDOR" type="BOOLEANINT" default="0"/>
<column name="ENABLED" type="BOOLEANINT" default="1"
javaName="Enabled"/>
<column name="LOGIN_ATTEMPT" type="INTEGER" default="1"
javaName="LoginAttempts"/>
<unique>
<unique-column name="LOGIN_NAME"/>
</unique>
</table>
<!-- transaction log -->
<table name="EVENT_LOG" idMethod="native">
<column name="LOG_ID" required="true"
primaryKey="true" type="INTEGER" autoIncrement="true"/>
<column name="USER_ID" required="true" type="INTEGER"/>
<column name="TRANSACTION_TYPE" type="INTEGER"/>
<column name="MESSAGE" type="VARCHAR" size="500"/>
<column name="TX_DATE" type="TIMESTAMP"/>
<foreign-key foreignTable="MYAPP_USER">
<reference local="USER_ID" foreign="USER_ID"></reference>
</foreign-key>
</table>
--
Jeff Painter
CEO and Founder of JiveCast
Software and analytics, made together
http://jivecast.com
301 Fayetteville St. Unit 2301, Raleigh, NC 27601
(919) 533-9024
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
