Logging with google Liferay 7Logging with google Liferay 7https://liferay.dev/en/c/message_boards/find_thread?p_l_id=119785333&threadId=1150652142024-03-29T11:53:58Z2024-03-29T11:53:58ZRE: Logging with google Liferay 7David H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1151337382019-09-07T14:17:38Z2019-09-07T14:17:38ZSure, but the question for me is "how do I do this with what I have today?"<br /><br /><br />Otherwise the solution to every forum post answer is "Submit a ticket to Liferay and wait for them to put a change in and publish it" and we'd all be it a tough spot.David H Nebinger2019-09-07T14:17:38ZRE: Logging with google Liferay 7Christoph Rabelhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1151179522019-09-07T11:58:29Z2019-09-07T11:58:29ZAh, now I understand what you mean. Thanks for explaining it.<br />I still think that the authentication modules could have a better interface/could be more extensible. I had problems with them several times.Christoph Rabel2019-09-07T11:58:29ZRE: Logging with google Liferay 7David H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1151314752019-09-06T22:09:45Z2019-09-06T22:09:45ZOh, sorry Christoph... My thought was that in order to put something into the ServiceContext to signal it was okay to save the change, it would be easier to override the MVC Action bound to the portlet where the form is for making changes... So you leave the auto login alone, it uses the unchanged ServiceContext there. But in the MVC action override for the portlet, you can add an attribute indicating the profile changes should be changed...<br /><br />The service wrapper then looks for the flag to pass the request down to the real UserLocalService, otherwise it just returns the unchanged user and bypasses the save.David H Nebinger2019-09-06T22:09:45ZRE: Logging with google Liferay 7Christoph Rabelhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1151078682019-09-06T08:24:58Z2019-09-06T08:24:58ZI still have no idea what you are talking about.<br />Google Authentication is an autologin module. There is no MVC action involved at all. There isn't even a form action. The user is redirected to google to authenticate and when he comes back, autologin is triggered.<br />Even if there were an MVC action, it wouldn't help at all. Look into the code!! The GoogleAuthorizationImpl class creates the service context inside of a method. It isn't a parameter, so there is no way to add something to it. The only way to change the behavior of that code is to copy it and override it with a higher service ranking.Christoph Rabel2019-09-06T08:24:58ZRE: Logging with google Liferay 7David H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1151065212019-09-06T02:15:44Z2019-09-06T02:15:44ZThe login action is going to be doing a lot of stuff. It may be hard or impractical to clone or maintain your own copy of that code just to control what the service context contains.<br /><br />But an MVC action command on a form submit going to send off to persistence by SB below?<br /><br />You're talking what, some validation code and parameter extraction code you have to copy and maintain? That kind of thing it won't matter if you miss a fixed "validation" rule in a new release or fixpack, the omission would not be critical. But if you don't maintain your login handling code? that could be a hidden issue...David H Nebinger2019-09-06T02:15:44ZRE: Logging with google Liferay 7Christoph Rabelhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1151000992019-09-05T14:10:04Z2019-09-05T14:10:04ZI have actually no idea what you mean by that. Why should it help at all to something in the login action?Christoph Rabel2019-09-05T14:10:04ZRE: Logging with google Liferay 7David H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1150916732019-09-05T01:00:40Z2019-09-05T01:00:40ZYou're only looking at the google auth side; you can easily adjust the service context on the MVC action command side to override what the portlet is doing during persistence... Overriding that, even if it takes building a custom action, is easier than tampering with the authentication code...David H Nebinger2019-09-05T01:00:40ZRE: Logging with google Liferay 7Christoph Rabelhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1150898322019-09-04T14:52:21Z2019-09-04T14:52:21ZSure, but if you look into the code, the service context is created with new inside of a protected method<br /> ServiceContext serviceContext = new ServiceContext();<br /> ...<br /> return _userLocalService.updateUser(...);<br />So, no way to add it there myself.<br />The GoogleAuthorization interface would have to be redesigned to allow me to reuse. Currently the only way to add my own data to the service context there would be to copy the Impl class and override the original with a higher service ranking.Christoph Rabel2019-09-04T14:52:21ZRE: Logging with google Liferay 7David H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1150849632019-09-04T13:44:09Z2019-09-04T13:44:09ZAh, but that's the beauty of the service context, you can add pretty much whatever you like. So if it came down to it, you could do an MVC action override where the user-triggered update occurs and add the value into the service context. <br /><br />Then your service wrapper just checks for the presence of the setting.Service context has lots of hidey holes you can use, the typical one is the attributes map, but you could also add to headers, override the command, ... Basically anything that a service-level request would not use, that's something you can take advantage of when trying to pass information.David H Nebinger2019-09-04T13:44:09ZRE: Logging with google Liferay 7Daniel Kęskahttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1150865232019-09-04T12:00:17Z2019-09-04T12:00:17ZFinally I added UserServiceWrapper module and overrided updateUser method only for Users that have googleId. Thanks for all suggestions!Daniel Kęska2019-09-04T12:00:17ZRE: Logging with google Liferay 7Christoph Rabelhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1150854992019-09-04T09:50:35Z2019-09-04T09:50:35ZI don't think you can distinguish between google and regular updates. The updateUser method of GoogleAutorizationImpl just changes email, firstname, lastname and I don't see a quick way to determine the difference. Maybe it would be a worthwhile to create a feature request to add some extra information to the service context like "UserSource" or "updateSource" or something.<br /><a href="https://github.com/liferay/liferay-portal/blob/7.2.x/modules/apps/portal-security-sso-google/portal-security-sso-google-impl/src/main/java/com/liferay/portal/security/sso/google/internal/GoogleAuthorizationImpl.java">https://github.com/liferay/liferay-portal/blob/7.2.x/modules/apps/portal-security-sso-google/portal-security-sso-google-impl/src/main/java/com/liferay/portal/security/sso/google/internal/GoogleAuthorizationImpl.java</a><br />I guess, the best way would be to implement the GoogleAuthorization interface with a higher service.ranking to replace above code/update method with <br /><a href="https://portal.liferay.dev/docs/7-1/tutorials/-/knowledge_base/t/creating-a-custom-osgi-service">https://portal.liferay.dev/docs/7-1/tutorials/-/knowledge_base/t/creating-a-custom-osgi-service</a> <br /><br />There is actually a general problem shown here: How to override these services and keep the original service? I mean, since it is internal, I can't derive from it. I need to replace it completely and I can actually just copy the class from github and implement it myself. Should work, but it isn't really nice from a maintenance point of view.Christoph Rabel2019-09-04T09:50:35ZRE: Logging with google Liferay 7David H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1150814792019-09-03T19:16:17Z2019-09-03T19:16:17ZProbably a number of ways to skin this cat...<br /><br />Modifying the GoogleLoginAction might be at the extreme end because you'd be interfering with the login process itself.<br /><br />I guess I would look at a UserLocalService wrapper to see if you can distinguish a call to update the user if it comes from a google account sync or from user activity.<br /><br />If you can, then you could just discard the update when originating from the google account sync and be least impactful on the overall login process.David H Nebinger2019-09-03T19:16:17ZRE: Logging with google Liferay 7Daniel Kęskahttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1150751092019-09-03T14:04:05Z2019-09-03T14:04:05ZI see, but that is the trick: there is a demand that user can modify his data in profile but next logging with google shouldn't overwrite his settings. I was thinking about modifying Liferay portlet GoogleLoginAction and delete there a possibility of updating user. So my final question is, can I do it and how to implement it to my project?Daniel Kęska2019-09-03T14:04:05ZRE: Logging with google Liferay 7David H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1150759372019-09-03T13:49:49Z2019-09-03T13:49:49ZSo then don't let the user on to the profile page to begin with...<br /><br /><br />If they do need to access some of the fields, you could either create a custom profile page where you control what they can update, or you could try a JSP override on the Liferay page to disable the locked fields.<br /><br />If you go the last route, I would probably put logic in there that would allow admins to update all fields, but disable for users. You never know when it may be necessary to force a change...David H Nebinger2019-09-03T13:49:49ZRE: Logging with google Liferay 7Daniel Kęskahttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1150745772019-09-03T11:38:03Z2019-09-03T11:38:03ZThank you David. One more thing: when somebody is logging with google a new row with his data appears in my database. Then, on my page, user can change his name in user profile on the portal. And when he is logging the another day, google overwrite his name to the name that is taken from google profile. And I would like just to prevent from updating the user data. I want user to be in the database, but after saving him, I do not want him to change all his data. Thank you!Daniel Kęska2019-09-03T11:38:03ZRE: Logging with google Liferay 7David H Nebingerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1150672392019-09-02T21:29:14Z2019-09-02T21:29:14ZYou cannot do this.<br /><br />All users must be in the Liferay database. It is the only way for Liferay to resolve foreign key references.<br /><br />Sure you can use third party authentication mechanisms like OpenID and SAML and LDAP, but at the end of the day all of the users are still going to be in the Liferay database.David H Nebinger2019-09-02T21:29:14ZRE: Logging with google Liferay 7Christoph Rabelhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1150658752019-09-02T15:46:05Z2019-09-02T15:46:05ZLogging or Login?<br />I guess, the latter. You probably need a Login post action class. It will trigger after aut