Hi Thomas,
sicher ist es aus Wartungsgründen nicht schön selbst das Surf Rollenmodell zu erweitern.
Wartung ist aber wie "echte" Sicherheit auch etwas was gegen die von dir skizzierte Lösung spricht.
Ich persönlich würde mich wundern warum ich mal user.isAdmin oder user.isGuestUser - ditto Authentication Elemente im XML, und außerdem noch andere Konstrukte sehe die im Grunde dem selben Zweck dienen.
Sicher gibt es einen guten Grund warum Webscripts dieses fixe Modell hat.
Weißt du, warum das so ist ?
Vielleicht weil historisch aus den dem Repo Code gewachsen ?
"Selbst" JEE kennt analog isUserInRole(…) schon seit jeher.
Gruß
Andreas
sicher ist es aus Wartungsgründen nicht schön selbst das Surf Rollenmodell zu erweitern.
Wartung ist aber wie "echte" Sicherheit auch etwas was gegen die von dir skizzierte Lösung spricht.
Ich persönlich würde mich wundern warum ich mal user.isAdmin oder user.isGuestUser - ditto Authentication Elemente im XML, und außerdem noch andere Konstrukte sehe die im Grunde dem selben Zweck dienen.
Sicher gibt es einen guten Grund warum Webscripts dieses fixe Modell hat.
Weißt du, warum das so ist ?
Vielleicht weil historisch aus den dem Repo Code gewachsen ?
"Selbst" JEE kennt analog isUserInRole(…) schon seit jeher.
Gruß
Andreas
Um nochmal auf eine konkrete Lösung zurückzukommen. Ich habe die Aufgabe "Verberge dies und das in share für user xy, oder die Gruppe abc" durch einfaches css gelöst:
1. Im HTML Grundgerüst Template org/alfresco/include/alfresco-template.ftl ein CSS kurz vor dem <body> als ein WebScript eingebunden.
2. Das Share Webscript overrides bekommt einen JS Controller overrides.get.js
3. im freemarker css template overrrides.get.css.ftl
Das Konzept lässt sich natürlich auch auf diverse andere Elemente der Seite übertragen. Einen kleine Trick braucht es noch, damit man CSS als WebScript rendern lassen kann. Dafür muss man css in der bean webscripts.formatmap konfigurieren. Ein Schnipsel-Beispiel wie man das bean überschreibt auf share seite. Das kann man sogar vielleicht noch weglassen, wenn man das CSS als "overrides.html" im Css-Tag einbindet.
Prinzipiell einfach, wenn man ein Template-Überschreiben akzeptieren möchte - die eine Zeile geht für mich gerade noch unter minimal invasiv durch
. Leider gibt es da imo kein Component um ein override.css per extension config reinzuhängen.
Grüße,
lothar
1. Im HTML Grundgerüst Template org/alfresco/include/alfresco-template.ftl ein CSS kurz vor dem <body> als ein WebScript eingebunden.
<!– css global overrides –>
<link rel="stylesheet" type="text/css" href="${url.context}/service/ecm4u/custom/overrides.css"/>
</head>
2. Das Share Webscript overrides bekommt einen JS Controller overrides.get.js
model.hideRepositoryNavigation = ganzKomplizierteBerechnungHier();
3. im freemarker css template overrrides.get.css.ftl
<#if hideRepositoryNavigation>
#global_x002e_header_x0023_default-app_repository {
display:none;
}
</#if>
Das Konzept lässt sich natürlich auch auf diverse andere Elemente der Seite übertragen. Einen kleine Trick braucht es noch, damit man CSS als WebScript rendern lassen kann. Dafür muss man css in der bean webscripts.formatmap konfigurieren. Ein Schnipsel-Beispiel wie man das bean überschreibt auf share seite. Das kann man sogar vielleicht noch weglassen, wenn man das CSS als "overrides.html" im Css-Tag einbindet.
<bean id="webscripts.formats" parent="webscripts.formatmap">
<property name="formats">
<props>
<prop key="css">text/css</prop>
….
Prinzipiell einfach, wenn man ein Template-Überschreiben akzeptieren möchte - die eine Zeile geht für mich gerade noch unter minimal invasiv durch
. Leider gibt es da imo kein Component um ein override.css per extension config reinzuhängen.Grüße,
lothar
Hallo zusammen,
ich denke der Thread hier zeigt auf, daß Bedarf besteht Spring Surf/-Webscripts in Punkto Sicherheit zu verbessern, oder ?
Der Ansatz etwas mittels templating conditionals auszublenden reicht für diverse (gar nicht weit hergeholte) Anforderungen einfach nicht aus und ist auch technisch nicht immer sauber - wenn z.B. vorher "überflüssigerweise" Controller Code läuft.
Und ja, mann kann einige Sicherheits-Themen mit ACLs abbilden und erschlagen. Aber es gibt durchaus auch Dinge (Rollen !, die sich nicht sinnvoll auf CRUD ACL Security reduzieren lasssen.
Was solls : Nobody is perfect !
Natürlich geht heute mit Modulen und Evaluatorn da mehr als früher. Das ist aber eben nicht konsistent analog admin oder user die ich auch in templates und den XML Descriptoren verwenden kann. Ich würde es einfach gut finden, wenn Webscripts/Surf konsistent für beliebige Rollen angepasst wird.
Ich habe fertig.
Gruß
Andreas
ich denke der Thread hier zeigt auf, daß Bedarf besteht Spring Surf/-Webscripts in Punkto Sicherheit zu verbessern, oder ?
Der Ansatz etwas mittels templating conditionals auszublenden reicht für diverse (gar nicht weit hergeholte) Anforderungen einfach nicht aus und ist auch technisch nicht immer sauber - wenn z.B. vorher "überflüssigerweise" Controller Code läuft.
Und ja, mann kann einige Sicherheits-Themen mit ACLs abbilden und erschlagen. Aber es gibt durchaus auch Dinge (Rollen !
, die sich nicht sinnvoll auf CRUD ACL Security reduzieren lasssen.Was solls : Nobody is perfect !
Natürlich geht heute mit Modulen und Evaluatorn da mehr als früher. Das ist aber eben nicht konsistent analog admin oder user die ich auch in templates und den XML Descriptoren verwenden kann. Ich würde es einfach gut finden, wenn Webscripts/Surf konsistent für beliebige Rollen angepasst wird.
Ich habe fertig.
Gruß
Andreas
