Eingabefelder in Portlet nur für Administrator sichtbar

[Timo Kurowski, modificado hace 9 años.]

Hallo zusammen,

ich habe ein paar Portlets von einem Kollegen bekommen, die Eingabefelder besitzen (textfields, dropdowns, Kalenderauswahl usw.). Diese sind als Administrator nutzbar, aber mit einem User nicht? Ich habe dem Benutzer alle Rechte gegeben, die ich im Portlet angeben konnte. Doch aus irgendeinem Grund verschwinden für den Benutzer alle Eingabefelder einfach. Eine Fehlermeldung gibt es nicht.

Wurde bei der Entwicklung eventuell etwas vergessen oder falsch gemacht? Da ich keine Fehlermeldung gesehen habe, wollte ich dies eigentlich ausschließen..

[Jan Geißler, modificado hace 9 años.]

Ohne den Code zu sehen natürlich schwer einzuschätzen...

[Timo Kurowski, modificado hace 9 años.]

Da stimme ich dir zu.. Diese Portlets sind leider recht umfangreich, von daher ist es schwer für mich einfach mal code zu posten.

Eine Sache ist mir aber aufgefallen:

boolean useFilter = (storageItemId!=0 || locationIdSource!=0 ||locationIdTarget!=0 || (dateStartSelect!=null && !"".equals(dateStartSelect))|| (dateEndSelect!=null && !"".equals(dateEndSelect)));
if (renderRequest.isUserInRole("power-user"))
{
%>
<aui:button-row>
	<aui:button onClick="<%= addTransactionURL.toString() %>" value="transaction-add" />
</aui:button-row>

"if (renderRequest.isUserInRole("power-user"))" Ich bin mir ziemlich sicher, dass diese Abfrage falsch ist, denn den "power-user" soll es später nicht geben, stattdessen soll eine eigene Rolle und natürlich der Admin diesen Button sehen können. Falls das tatsächlich die Ursache ist, stellt sich die Frage wie ich das löse, ohne meine Rolle hart in den Code zu verdrahten.

Am Liebsten würde ich diese Abfrage so abändern, dass eine Permission in der Konfiguration des Portlets für die Rolle gesetzt werden soll, die ich festlege. So wie z.B. "Ansicht".

[Jan Geißler, modificado hace 9 años.]

Am Liebsten würde ich diese Abfrage so abändern, dass eine Permission in der Konfiguration des Portlets für die Rolle gesetzt werden soll, die ich festlege. So wie z.B. "Ansicht".

Ich stimme voll und ganz zu.
Dazu musst du folgende Sachen machen:
Die permission die du brauchst definieren. Siehe dazu diesen Artikel:
https://www.liferay.com/de/documentation/liferay-portal/6.0/development/-/ai/security-and-permissions
Dann auf die entsprechende permission im Code zu prüfen.

Gruß
Jan

[Olaf Kock, modificado hace 9 años.]

Die Rechteabfrage sollte eher über "Permissions" gehen, die dann beliebigen Rollen zugeordnet werden können.

Eine mögliche Dokumentation ist auf dev.liferay.com zu finden. Die Abfrage folgt dann eher dem Schema "Hat der aktuelle Benutzer das Recht X auf der Resource Y?" als "ist der aktuelle Benutzer in Rolle Z?" - das Recht X kann dann in beliebig vielen Rollen vergeben werden.

[Timo Kurowski, modificado hace 9 años.]

Moin,

ich konnte der Anleitung so weit gut folgen, bis zu einem Punkt:

Wenn ich in der JSP abfrage, frage ich (wie in der Anleitung beschrieben) folgendes:

if (permissionChecker.hasPermission(scopeGroupId, "de.irgend.ein.text.hier", scopeGroupId, "TEST_A"))

Dieser scheint aber, ob jetzt in der Portlet Konfiguration gewählt oder nicht, immer "null" zurück zu geben..

[Jan Geißler, modificado hace 9 años.]

Check dis out:

if (permissionChecker.hasPermission(scopeGroupId, "hier.die.portlet.id.wenn.ich.mich,nicht.arg.täusche", scopeGroupId, "TEST_A"))

[Timo Kurowski, modificado hace 9 años.]

Ich bin mir nicht ganz sicher, wo der Unterschied liegt zwischen deinem und meinem Code?

das "irgend.ein.text.hier" ist der model-name aus der .xml. Zumindest steht das so in der Anleitung.

[Olaf Kock, modificado hace 9 años.]

Sieht gut aus - unter einer Voraussetzung (die nicht in javadoc steht):

boolean hasPermission(long groupId, String name, String primKey, String actionId)
    Returns true if the user has permission to perform the action on the resource.
    Parameters:
        groupId - the primary key of the group containing the resource
        name - the resource's name, which can be either a class name or a portlet ID
        primKey - the primary key of the resource
        actionId - the action ID 
    Returns:
        true if the user has permission to perform the action on the resource; false otherwise

Was dort nicht steht, ist dass primKey durch groupId ersetzt wird, sofern es keinen Primärschlüssel gibt. Das ist üblicherweise für "Top Level" Operationen der Fall, also "ADD_OBJECT" (oder wie auch immer die heißen), die nicht auf einem bestimmten Objekt ausgeführt werden (z.B. weil es noch gar nicht existiert). Per Konvention ist der Model-Name (Parameter name) der Package-Name der Interface-Klasse. D.h. aufgrund der Beschreibung würde ich in der Datei default.xml einen model-resource Eintrag für "de.irgend.ein.text.hier" erwarten, sowie - darin geschachtelt - eine Action "TEST_A". Wie sieht denn die default.xml aus? Ist sie in portlet.properties eingetragen?

[Timo Kurowski, modificado hace 9 años.]

Die default.xml sieht so aus:

<!--?xml version="1.0"?-->

<resource-action-mapping>
	 <resource file="resource-actions/container.xml" />
</resource-action-mapping>

und die container.xml dann so:

<!--?xml version="1.0"?-->

<resource-action-mapping>

	<portlet-resource>
		<portlet-name>location-listing</portlet-name>
		<permissions>
			<supports>
				<action-key>ADD_TO_PAGE</action-key>
				<action-key>CONFIGURATION</action-key>
				<action-key>VIEW</action-key>
			</supports>
			<site-member-defaults>
				<action-key>VIEW</action-key>
			</site-member-defaults>
			<guest-defaults>
				<action-key>VIEW</action-key>
			</guest-defaults>
			<guest-unsupported />
		</permissions>
	</portlet-resource>

	<portlet-resource>
		<portlet-name>location-listing</portlet-name>
		<permissions>
			<supports>
				<action-key>TEST_A</action-key>
				<action-key>CONFIGURATION</action-key>
				<action-key>VIEW</action-key>
			</supports>
			<site-member-defaults>
				<action-key>VIEW</action-key>
			</site-member-defaults>
			<guest-defaults>
				<action-key>VIEW</action-key>
			</guest-defaults>
			<guest-unsupported>
				<action-key>CONFIGURATION</action-key>
			</guest-unsupported>
		</permissions>
	</portlet-resource>

	<model-resource>
		<model-name>de.irgend.ein.text.hier</model-name>
		<portlet-ref>
			<portlet-name>location-listing</portlet-name>
		</portlet-ref>
		<permissions>
			<supports>
				<action-key>TEST_A</action-key>
			</supports>
			<site-member-defaults>
				<action-key>TEST_A</action-key>
			</site-member-defaults>
			<guest-defaults />
			<guest-unsupported>
				<action-key>TEST_A</action-key>
			</guest-unsupported>
		</permissions>
	</model-resource>

	<model-resource>
		<model-name>de.irgend.ein.text.hier</model-name>
		<portlet-ref>
			<portlet-name>location-listing</portlet-name>
		</portlet-ref>
		<permissions>
			<supports>
				<action-key>ADD_LOCATION</action-key>
			</supports>
			<site-member-defaults>
				<action-key>ADD_LOCATION</action-key>
			</site-member-defaults>
			<guest-defaults />
			<guest-unsupported>
				<action-key>ADD_LOCATION</action-key>
			</guest-unsupported>
		</permissions>
	</model-resource>

	<model-resource>
		<model-name>de.irgend.ein.text.hier</model-name>
		<portlet-ref>
			<portlet-name>location-listing</portlet-name>
		</portlet-ref>
		<permissions>
			<supports>
				<action-key>ADD_LOCATION</action-key>
				<action-key>DELETE</action-key>
				<action-key>PERMISSIONS</action-key>
				<action-key>UPDATE</action-key>
				<action-key>VIEW</action-key>
			</supports>
			<site-member-defaults>
				<action-key>ADD_LOCATION</action-key>
				<action-key>VIEW</action-key>
			</site-member-defaults>
			<guest-defaults>
				<action-key>VIEW</action-key>
			</guest-defaults>
			<guest-unsupported>
				<action-key>UPDATE</action-key>
			</guest-unsupported>
		</permissions>
	</model-resource>

</resource-action-mapping>

Die default.xml ist in den portlet.properties eingetragen.

Was mir aufgefallen ist: ich habe zum Debuggen mal folgendes in meine view.jsp geschrieben:

boolean perm = (permissionChecker.hasPermission(scopeGroupId, "de.irgend.ein.text.hier", scopeGroupId, "TEST_A"));

Dies müsste ja einen Wert perm = false bzw. true zurück geben.

Interessanterweise wird perm erst gar nicht geschrieben. Ich habe einen Breakpoint an dieser Stelle gesetzt, und es ist, als würde diese einfach ignoriert werden. Keine Fehlermeldung, keine Reaktion.

[Olaf Kock, modificado hace 9 años.]

permissionChecker.toString: &lt;%=permissionChecker%&gt; <br>
scopeGroupId: &lt;%=scopeGroupId%&gt; <br>
hasPermission  &lt;%=permissionChecker.hasPermission(scopeGroupId, "de.irgend.ein.text.hier", scopeGroupId, "TEST_A")%&gt;<br>

[Timo Kurowski, modificado hace 9 años.]

Ich bin mir ehrlich gesagt nicht sicher, was du mir damit mitteilen willst ^^.

[Olaf Kock, modificado hace 9 años.]

'tschuldigung, das kam etwas aus der Hüfte geschossen.

Ich konnte mit der im Debugger übersprungenen Anweisung nichts anfangen, daher hab ich die mal auf mehrere Anweisungen aufgeteilt, um zu sehen, was passiert. Außerdem: Damit wird die JSP mal wieder aktualisiert und es ist klar, ob wirklich die letzte Version verwendet wird.

[Timo Kurowski, modificado hace 9 años.]

Hmm interessant, egal was ich in der jsp schreibe, es ist als würde ich einfach nur leerzeilen hinzufügen.. Der Debugger stoppt zwar an den Stellen, aber sie werden nicht bearbeitet. Ich kann alles, auch println versuchen, ohne Erfolg...

Ich vermute mal, dass die neuere Version nicht erkannt wird.. Stellt sich mir nur die Frage wieso, und vor Allem wieso es dann keine Fehlermeldungen gibt.

[Olaf Kock, modificado hace 9 años.]

Vielleicht Undeploy/Deploy statt Redeploy? Datei- und Verzeichnisrechte prüfen? Wenn Liferay zwischendurch mal als root lief, kann ein unprivilegierter Benutzer plötzlich keine Daten mehr schreiben - weder beim Deployment noch zur Laufzeit (temp, work). Nach undeploy ist sicher alles weg...