A strange problem has been discovered recently. A portlet, anonymous user access is not a problem, if the user logged on instead of a permission issue, the message shows "You do not have access to this portlet required permissions to the role."
7.1 Source Code Analysis
Try to find out the cause of the problem by analyzing the source code.
Find a resource file
You-do-not-have-the-roles-required-to-access-this-portlet= you do not have a role to access the permissions required for this portlet.
Find the location of "You-do-not ..."
Appears in file portal-web/docroot/html/portal/portlet_access_denied.jsp
Find where the portlet_access_denied.jsp appears
There are two places in the show
1, Tiles-defs.xml
<definition name= "portal.portlet_access_denied" extends= "Portlet" >
<put name= "portlet_content" value= "/portal/portlet_access_denied.jsp"/>
</definition>
2, in portal/portal-web/docroot/html/common/themes/portlet_content.jsp
<c:if test= "<%=!portletdisplay.isaccess ()%>" >
<liferay-util:include page= "/html/portal/portlet_access_denied.jsp"/>
</c:if>
Find Portal.portlet_access_denied
In the Portal/portal-web/docroot/web-inf/struts-config.xml file
<forward name= "/portal/portlet_access_denied" path= "portal.portlet_access_denied"/>
Find/portal/portlet_access_denied
In the Java file Portal/portal-ejb/src/com/liferay/portal/struts/portletrequestprocessor.java
private static final String _path_portal_portlet_access_denied =
"/portal/portlet_access_denied";
Find _path_portal_portlet_access_denied
is also in the Java file Portletrequestprocessor.java, appearing on line No. 356. Set a breakpoint here to see if this line is going to be a problem.
After testing, it seems that no breakpoint has not taken effect, indicating that this line is not a problem. Then try to start a check from another line.
Check Com.liferay.portal.theme.PortletDisplay.isAccess ()
This place is a bit of a hassle, trying a couple of minutes.
1, set breakpoints, and modify the value. Set the breakpoint on Isaccess () and set the condition to _access==false, and it does pause at this point. Try to change the value of _access from false to true. However, the same problem still occurs, and the page still shows no permissions.
2, or set breakpoints, and set conditions. Open two separate windows, one login, one does not log in. Refresh each to see if it will stop on the breakpoint.
Neither of the two methods found any meaningful clues. Suspecting that portletdisplay in a JSP is not an instance of Com.liferay.portal.theme.PortletDisplay.
3, modify the JSP file, show the Portletdisplay.tostring ().
7.2 Rearrange ideas, view the source code
The idea of the front is a bit messy, re checking. As mentioned earlier, there are two possible ways to display information with no permissions in two JSPs. During the simple period, I placed a different content in two JSP, and found that the error message came from the first line, that is, the error was thrown in line No. 356 of Portletrequestprocessor.java.
Set breakpoints in this function, tested with anonymous users and logged-in users, and found that the Processroles () function was not executed at all if it was an anonymous user. The preliminary conclusion to this point is that only the logged-on user will invoke Processroles () for the role's judgment.
Back to the current issue, the surface reason has been found, related to my business: I want to make the necessary changes on the basis of the calendar portlet, but do not want to move liferay own things. So, what I want to do is to copy the JSP a new one and make a new portlet. But it's probably not set up somewhere.
if (!strutspath.equals (Portlet.getstrutspath ())) {
throw new Principalexception ();
}
When judging, strutspath= "Ext/calendar", and Portlet.getstrutspath () is "Calendar". Because of the path cause. The final check found that when the Struts-path was defined in Liferay-portlet-ext.xml, it was written as <struts-path>calendar</struts-path>, and modified to < Struts-path>ext/calendar</struts-path>. Re-publish startup test, normal.
7.3 A conclusion
Through some of my development encounter, the issue of permissions, in addition to the actual permissions set errors, the general situation is the problem of struts path. There are two points to note:
1, the portal-ext.xml defined in the struts path, and liferay-portlet-ext.xml in the value of <struts-path> can correspond. If Portal-ext.xml inside is/ext/calendar/view, then Liferay-portlet-ext.xml is Ext/calendar. After Qiatouquwei, be sure to be consistent.
2, the same portlet used in all the struts action, the path should be consistent, that is, after Qiatouquwei, should be liferay-portlet-ext.xml in the value of <struts-path>.
