We Keep Coding

Change default registration behavior in Keycloak

We have recently switched to Keycloak to handle the login to our website.
It's still possible to register and Keycloak has a user registration page, but I basically need to change the definition of 'registrating'.
By default it means "insert a new user in the DB with the info given by the user through the registration form". But that's not what we want, we already have all the users that CAN register in our DB, and registrating as a user pretty much means updating a record in our DB.
I have already made changes to the a few classes and redeployed them by packaging them and then adding the Jar to the \deployments directory. But I can't seem to find the classes that I have to change to get the registration page to behave the way I want.
How can I change the default behavior of the registration page? What classes do I have to change?

I've never do this, but i'd take a look to the user store SPI and authenticator SPI.
I suggest you in writing directly in the Keycloak discourse forum (https://keycloak.discourse.group/) . They will surely give you a hand.
PS: with SPI you'll add features to Keycloak, but in your case i think that you'll need also to change the GUI. See Keycloak Themes in the official doc.

Adding Iframe from module as portlet in liferay7

I am new to liferay and using Liferay7. Now Instead of adding iframe manually in the portal i want to make a module and add it as a portlet and then want to make the iframe url dynamic so that i can change the url of the iframe based on some UI action in the portal. Any suggestions as to how it can be done?

If you aware, there's already liferay iframe portlet available.
http://www.liferay.com/community/wiki/-/wiki/Main/Iframe%20Portlet
You can either customize it or write your custom iframe event portlet.
Custom iframe event portlet will listen to any events from other portlet and act accordingly. You can write event portlet using following link, check for Event Inter-portlet Communication
https://web.liferay.com/community/wiki/-/wiki/Main/Portlet+to+Portlet+Communication
From other portlet you can either trigger this event which will force iframe portlet to change url.

How can I get the timestamp of deploying and loading process of a portlet in liferay 6?

My scenario is the next one, I want to get the current state of the portlets availables in the liferay portal, but the main idea is to generate a chart or some graphic resource and fill it with the information of the exact timestamp when the portlet started to being deployed and the timestamp when the portlet is fully loaded into the portal, right now I don't know how can I get these timestamps, I tried to read it from the catalina.out but for my project leader is not correct to do that. thank you in advanced

You have two options, create a HotDeployListener or listen to messagebus HOT_DEPLOY messages
Option 1: HotDeployListener
When a portlet or any other plugin is deployed, Liferay executes a list of HotDeployListener listeners that are defined in hot.deploy.listeners property of portal.properties
See default value in Hot Deploy section of portal.properties
The hot deploy listener receives a HotDeployEvent object that contains information about portlet is being deployed, for example servletcontext can be retrieved
You have to implement your own HotDeployListener, see javadoc documentation and add it your portal-ext.properties.
You have to copy the default value of hot.deploy.listeners property to your portal-ext.properties and add to that list yours listener.
For more information see documentation in portal.properties file:
Input a list of comma delimited class names that implement com.liferay.portal.kernel.deploy.hot.HotDeployListener. These classes are used to process the deployment and undeployment of WARs at runtime.
The listeners are invoked in the order defined by this property. PluginPackageHotDeployListener must always be invoked first. SpringHotDeployListener must always be invoked before ServletContextListenerHotDeployListener. MessagingHotDeployListener must always be invoked last.
Option 2: listen to messagebus HOT_DEPLOY messages
After portlet is deployed, a HOT_DEPLOY message is sent to Liferay message bus by the MessagingHotDeployListener, see: portal-impl/src/com/liferay/portal/deploy/hot/MessagingHotDeployListener.java#L70-L75
You can listen to that event creating a listener and call to MessageBusUtil.registerMessageListener(DestinationNames.HOT_DEPLOY, myListener) or MessageBusUtil.registerMessageListener("liferay/hot_deploy", myListener).
The listener must implement MessageListenerinterface, see javadoc documentation
For more information about Liferay messagebus see following links:
https://dev.liferay.com/develop/tutorials/-/knowledge_base/6-2/liferays-message-bus-system
http://www.liferaysavvy.com/2013/11/lifeay-message-bus-portlethandling-bulk.html
https://web.liferay.com/es/community/wiki/-/wiki/Main/Message+Bus

SecureSocial: How to modify the signup system (UsernamePasswordProvider)?

I'm implementing a signup system by using UsernamePasswordProvider. I want a user to be able to signup directly instead of firstly putting his/her email and waiting for a token. Moreover, I want to modify the signup form by adding/deleting some input fields. However, I can't find any document mentioned how to achieve these requirements. Any help would be appreciated.

The current stable version - 2.1.3 as of this writing - does not make it easy to customize the flow. With the latest changes in master you can override the built in registration controller and add the changes you need.
To accomplish what you want the best would be to not include the default registration routes and add your own that point to your custom controllers directly.
Keep in mind that the default flow prevents leaking information about the user base. If you make your users fill a form and they enter an existing email address you will have to show an error saying the account exists. That can give information to a potential attacker to target specific emails.

You should create custom views that extend TemplatesPlugin (or ViewsPlugin, in the newest version). This information is explained in securesocial website.

JSF2 - Flexible way on restrict access on certain xhtml pages, apply simple logic on access

Hi I am actually trying to get tips or ideas on a very specific problem. The technology context is
java web app with JSF 2.1 .
So I have a simple java ee app powered by JSF 2.1. The structure is the following
\webapp
\WEB-INF
\templates
header.xhtml
menu.xhtml
web.xml
\secured
\operation1
op1.xhtml
\operation2
op2.xhtml
\operation3
op3.xhtml
userhome.xhtml
login.xhtml
I have one #WebFilter that restricts the access to /secured/* in case the 'user' bean is not set (Actually a Session Scoped Bean).
At the same time upon login, I create a dynamic Menu depending on the user credential. this menu (MenuItems) point to one or more operations (xhtml pages).
So far so good, the user logins, the menu is dynamic, links are being generated and upon clicking he/she can navigate to whatever operations he/she is supposed to do.
My problem is that I can not decide on an elegant way on restricting access to the absolute url of these pages . If user1 is 'authorized' to execute operation1 but not operation2 or operation3, currently I can not find the most elegant way on checking his session state and applying a generic rule (navigation rule?), if the actual web user, writes on the url bar the absolute path of the operation.
'/secured/operation1/op2.xhtml'
What is the most JSF2 compatible way on achieve that kind of requirement?
I have tried the preRenderView on each separate opxx.xhtml page , unfortunately it did not work + i dont like repeating it on each operation
Many thanks for your tips.

Security in web applications is a more advanced topic. Basically you have two ways:
Container based: This means your servlet container like Tomcat does the job for you (recommended)
Application based: You have to do the job on your own
How to setup container based security is explained in detail here. To summarize it, you have to implement a simple form (no JSF form!) with a specific action and specific ids for the username and password field. Afterwards you can easily restrict access to specific URL patterns using your web.xml file. In the web.xml file you restrict access to certain URL patterns for certain user roles. The mapping from usernames to user roles is done by a security realm. How to setup a security realm is desribed e.g. for Tomcat here.
If you want to implement security on your own, you have to implement a ServletFilter that inspects all requested URLs and either forwards users that are not logged in to your login form or passes the request through if the user is authorized. If the user is not authorized to see the page, you will have to forward the user to your error page. As CDI injection does not work for ServletFilter, you will have to lookup the bean that stores the information about your user (logged in, rights) from the HttpSession.