掲示板

custom table insted of user_ table for Authentication?

11年前 に Bharani Ravi Kanth によって更新されました。

custom table insted of user_ table for Authentication?

Junior Member 投稿: 63 参加年月日: 12/01/20 最新の投稿
Hello Guys,

Since liferay uses default (users_)table to store the information of the user. is there any way to create a custom table where it stores user data and also authentication must also be done through this custom table.

Regards

Bharani
thumbnail
11年前 に Sandip Patel によって更新されました。

RE: custom table insted of user_ table for Authentication?

Regular Member 投稿: 205 参加年月日: 11/01/05 最新の投稿
Hi Ravi,

Liferay use User_ table for store the information. Instead of create custom table, use custom field for User model.
thumbnail
11年前 に Juhi Kumari によって更新されました。

RE: custom table insted of user_ table for Authentication?

Expert 投稿: 347 参加年月日: 11/12/12 最新の投稿
Hi Bharani,
Why you want same copy of user table?? I don't think this is an easy task. You can extend user_ table with you custom field easily.
But don't replace user_ table.

Regards
Juhi
11年前 に MICHAIL MOUDATSOS によって更新されました。

RE: custom table insted of user_ table for Authentication?

Regular Member 投稿: 110 参加年月日: 11/10/04 最新の投稿
Bharani Ravi Kanth:
is there any way to create a custom table where it stores user data

I supppose ppl here are right when they say you must expand this table in order to use more fields for a user. However you can create an Entity of your own having the userId as one of their fields and its on your applications responsibility to populate these and how it will do it.

Bharani Ravi Kanth:
also authentication must also be done through this custom table.

I haven't try this but I think you should look at ## Authentication Pipeline section of the portal.properties file (look the descrption and the auth.pipeline.pre and auth.pipeline.post properties, which you can override in a hook (I think you actually/practically append classes by overriding it in a hook). Following the documented info, maybe you can affect the authentication process by examining the additional info you want to introduce to the User entity (either by extending the User_ table or by adding a table of your own) and manipulate the outcome of the validation process accordingly... (I suppose that all this should happen in the code of the class that implements the documented interface)

As I've already said, I haven't really tried this ever, so this is just a hunch, but according to the documentation, this sounds like a relevant property to deal with...

So I hope I helped a bit...
thumbnail
11年前 に David H Nebinger によって更新されました。

RE: custom table insted of user_ table for Authentication? (回答)

Liferay Legend 投稿: 14914 参加年月日: 06/09/02 最新の投稿
Bharani Ravi Kanth:
is there any way to create a custom table where it stores user data


You do not want to do this. Instead you should be looking at the custom fields (expando) to add whatever you need for the users. Makes the data available anywhere you need it (if you get the User object you have access to the expando bridge for accessing the custom fields), but most importantly it will not break all of the Liferay stuff that relies upon this table being properly populated.

authentication must also be done through this custom table.


You can write your own auth process to leverage the expando fields for the given user.
thumbnail
11年前 に Tanaji M. Londhe によって更新されました。

RE: custom table insted of user_ table for Authentication?

Regular Member 投稿: 194 参加年月日: 12/04/25 最新の投稿
Is it possible to remove some unnecessary fields from user_ or any other table (which is created automatically by Liferay)?
I heard that we can expand the table using liferay Expando concept.
11年前 に MICHAIL MOUDATSOS によって更新されました。

RE: custom table insted of user_ table for Authentication?

Regular Member 投稿: 110 参加年月日: 11/10/04 最新の投稿
Tanaji M. Londhe:
Is it possible to remove some unnecessary fields from user_ or any other table (which is created automatically by Liferay)?
I heard that we can expand the table using liferay Expando concept.


I don't think you can remove the fields because that would imply refactoring the related programmatic entity, which resides in Liferay code. (And I don't think you want to do that - i dont even know if it is possible at all through an -ext plugin. Of course it is possible if you tamper with the core code and rebuild emoticon ) The most common answer you 'd get is that if you dont need a field, just don't use it! That said, I'm waiting for others to see what they'd propose