[liferay7]I want to overwrite existed autologin url pattern

[Ying Wang，修改在6 年前。]

I have found how to create custom filter by 'blade' example. But I want to overwrite an existed portal filter, for example, autologin filter.

More exactly , I want to change the url pattern for this filter. I need to make it only work on some specifiied page, for example, some 'public page'.
By default, this filter should work on some pages that we need to login to visit.
Here is the code I found in source of liferay: liferay-web.xml

<filter-mapping>
		<filter-name>Auto Login Filter</filter-name>
		[b]<url-pattern>/c/portal/login</url-pattern>[/b]
		<dispatcher>FORWARD</dispatcher>
		<dispatcher>REQUEST</dispatcher>
	</filter-mapping>

By liferay 6.2, I only need to define new filter url pattern rule in lifery-hook.xml. But this seems not recommeded in liferay 7.
Can anyone give me some advice ?

[Andrew Jardine，修改在6 年前。]

I'm not sure I totally understand your question -- do you mean you want to have, for example, /show/signin to have the same behaviour as /c/portal/login? -- meaning if Liferay receives a request for a /show/signing, and the user is not authenticated, it will show them the login dialog?

[Ying Wang，修改在6 年前。]

I am sorry that I didn't describe question enough clearly because of my poor English.
My business requirement:
1)Some administrator portlets are deployed on the private pages. Only Administrator Users will use them. The Administrator should enter username and password to complete login. I suppose this is a normal login operation.
2)Some contents are deployed on the public page, some client users will visit them. Because I want to do user behavior analytics, these client users should login to liferay site, before they can see these contents. I hope they will autologin liferay site by clicking a url in third party site.

I want to overwrite the "Auto Login Filter" default configuration. By default, the filter will be triggered, when url '/c/portal/login' is requested. But I hope it is triggered, when url '/web/*' (public page) is requested.

[Andrew Jardine，修改在6 年前。]

Hi Ying,

There is certainly no need to apologize for your English. I have a son who is now 7 and is in the process of learning how to read and write English (obviously he speaks it fluently). Helping him with his homework has made me realize just how stupid (and difficult) the English language is to learn -- especially when I compare it to other languages I speak (French and Spanish). But that's a topic for another thread

Ok. now that you have given a little more detail I think the correct answer to your question is that you are going about it wrong. Here is how I would change your solution (if possible). Liferay provides a solution for adding custom (plugins) to the Control Panel. For things that require the Administrator role, you should create these modules using this technique. In earlier versions of Liferay these were called, as I mentioned "Control Panel Portlets" -- but the new nomenclature to use in Liferay 7 is a "Panel App". There is blade template that you can use as a starter and you can learn more about how to build a panel app here: https://dev.liferay.com/develop/reference/-/knowledge_base/7-0/panel-app-template. Using this approach means that you don't have to use a private page to host your admin portlets.

Now, for the second part. Don't map /web/* to secured resources -- that is why you have the /group/* mapping. The correct implementation would be to leave your public assets on the /web/* (public pages) and then anything that requires a login to hide behind the /group/* -- this way you can use the default security pipeline in Liferay and the expected behaviour. It's important to consider not just the problem you are solving today but also what kind of pain you bring to yourself in the future when you go to upgrade -- twisting the portal like this will make a mess.

... So that is how you do it right. If you are hell bent on doing it wrong (I surely hope that you are not), then I would use a proxy to route accordingly. You could register your own struts action to do your custom authentication, and then use the proxy to handle the routing. So your admin page would continue to be protected by /c/portal/login, but then your /web/* would be routed to /c/portal/customauth (or whatever you use for your pattern). Then you would need to make sure that whatever is required to check for a valid session exists. The thing is that the /web/* mapping doesn't require the auth pipeline to be executed so I imagine that you are going to have a nightmare of a time with distinct user sessions and the like. Most of the time custom authentication is paired with Liferay so that authentication may be handled by an external tool (let's say an OAuth service for example) but then once successful, an auto login occurs at Liferay. I'm not sure you can trigger and auto-login for the /web/* url pattern. I suppose you could change the servlet filters so that /public/* was used for public pages and /web/* was using in place of /group/* but honestly that is just more mess to contend with later.

I would strongly advise that you do it the right way.

[Ying Wang，修改在6 年前。]

Thanks for your reply.
I still need it automatically login when click a link in the thirty party site. (request with token or cookie to make me understand who is visiting)
But if I opened Auto Login Function， it will affect whole portal. All the access will trigger an automatically login.
Can I specify an scope for the Auto Login Filter? I want to change url pattern for this filter. How should I do?

[Andrew Jardine，修改在6 年前。]

Liferay actually comes with several login filters already configured.

 #
    # Input a list of comma delimited class names that implement
    # com.liferay.portal.kernel.security.auto.login.AutoLogin. These classes
    # will run in consecutive order for all unauthenticated users until one of
    # them returns a valid user ID and password combination. If no valid
    # combination is returned, then the request continues to process normally.
    # If a valid combination is returned, then the portal will automatically
    # login that user with the returned user ID and password combination.
    #
    # For example,
    # com.liferay.portal.security.auto.login.remember.me.RememberMeAutoLogin
    # reads from a cookie to automatically log in a user who previously logged
    # in while checking on the "Remember Me" box.
    #
    # This interface allows deployers to easily configure the portal to work
    # with other SSO servers. See
    # com.liferay.portal.security.sso.cas.internal.auto.login.CASAutoLogin for
    # an example of how to configure the portal with Yale's SSO server.
    #
    # This property is not read by the portal except for portal properties
    # overridden by liferay-hook.xml. It remains here only as a reference.
    #
    #auto.login.hooks=com.liferay.portal.security.sso.cas.internal.auto.login.CASAutoLogin,com.liferay.portal.security.sso.facebook.connect.auto.login.FacebookConnectAutoLogin,com.liferay.portal.security.sso.ntlm.auto.login.NtlmAutoLogin,com.liferay.portal.security.sso.openid.auto.login.OpenIdAutoLogin,com.liferay.portal.security.sso.opensso.auto.login.OpenSSOAutoLogin,com.liferay.portal.security.auto.login.remember.me.RememberMeAutoLogin

It looks like, by default, they are disabled in Liferay7, but in older versions I believe it was the opposite. There is a servlet filter that is used to load the classes and then runs through them. Let's say you have 3 filters configured (A, B and C). The auto login will process A, and if it fails, got to B, then to C. If however A succeeds (auth works), then B and C are not executed because we have a valid result.

The point is that with the auto login classes the practice is to write whatever logic you need. So if you need to check a cookie or a token, then you put that logic in your custom auto login class. You then add your class to the list -- so A, B, C, and your custom class D. If A --> C fails, then they get to your D and if your D passes, they get access. Otherwise, no dice -- and you get the login page to enter credentials.

The auto login class is a global configuration which means, yes, it is applicable to all portal instances and sites. You could scope the filter if you need to (in the filter class) using a custom setting that allows you to scope the filter by domain -- bottom line, the need to apply it to one part of your install and not another is not something that can't be worked around.