2016-12-20 2 views
0

Wir verwenden derzeit einen generischen Bericht, der von mehreren Benutzergruppen unterschiedlich verwendet wird. Wir haben dies ermöglicht, indem wir verknüpfte Berichte mit verschiedenen Einstellungen für versteckte Parameter erstellt haben (z. B. "Spalte x anzeigen", "Funktion y aktivieren"). Diese Einstellungen (Parameter) werden auch für andere Berichte benötigt, daher geben wir sie mit Go to ... Action weiter.Übergeben von Befehlen mit URL lässt Parameter anfällig

das Aussehen zu schaffen und fühlen wir uns nach sind, passieren wir einige auch zusätzliche Parameter, HTML Viewer commands und Report Server commands wie &rc:Parameters=False (reference).

Leider bleibt uns nur die Option Go to URL, da Microsoft diese Befehle für Go to Report nicht implementiert hat. Das bedeutet, dass wir unsere Einstellungen (die versteckten Parameter) in der URL weitergeben müssen. Dies führt zu einem Sicherheitsproblem, Beispiel: &PARAMETER_ENABLE_FEATURE_Y=False.

Der Benutzer könnte diesen Parameter in der URL bemerken und erhält so die Möglichkeit, diese Funktion durch Bearbeiten der URL zu &PARAMETER_ENABLE_FEATURE_Y=True zu aktivieren.

Also meine Frage ist: Wie kann ein Action in Reporting Services verwenden, während der Benutzer zu verhindern, dass unsere sensiblen Parameter der Bearbeitung und während in der Lage zu sein HTML Viewer commands und Report Server commands zu benutzen?

+0

Sie können einen Bericht mithilfe von POST anstelle von GET aufrufen. POST setzt die Parameter in den Hauptteil des Posts statt auf die URL (was GET tut). Sie können dies wahrscheinlich mit Javascript tun. Allerdings: ein Benutzer kann immer noch die Post-Parameter mit F12-Tools sehen, und schlimmer ... aus irgendeinem Grund macht SSRS dann die Post in eine GET, so dass Sie sie auf der URL sowieso sehen –

Antwort

1

Sie werden nie vollständige Sicherheit in diesem Sinne erhalten, wenn Sie absolut URL-basierte Parameter verwenden müssen.

Wenn Sie über die URL navigieren, können Sie Parameterwerte nur ausblenden, ohne sie hart zu codieren, um sie datengesteuert zu machen. In Ihrem Szenario ist dies jedoch nicht 100% sicher, da Sie weiterhin den Wert übergeben müssen, der Ihre datengesteuerten Parameter ausfüllt.

Diese Ebene der Verschleierung ist wahrscheinlich ausreichend und kann erreicht werden, indem Sie eine Liste von jeder Parameterkombination oder nur die von Ihnen benötigten zusammenstellen und eine ID zuweisen, die Sie in einem Dataset aufrufen können. Dies kann natürlich immer noch von Ihren Benutzern geändert werden, sollten sie neugierig werden und eine Pflege sein können.

Ich würde sagen, Ihre einzige andere Option ist, die URL-Leiste vollständig auszublenden, indem Sie eine Zielseite für Ihre Berichterstattung bereitstellen und alles in einem Iframe anzeigen. Dieser Rahmen kann mit einem Javascript-Link in Ihrem Go To URL gezielt werden:

="javascript:void(window.open('URL to open','iFrame Name'))" 

Wenn Sie in der Lage sind, obwohl, ich würde Ihnen Gruppe Benutzer in Active Directory-Sicherheitsgruppen beraten und dann eine Sammlung von Berechtigungen erhalten und Anpassungen pro Gruppe. Sie können dann prüfen, zu welchen Gruppen ein Benutzer gehört, indem Sie einen benutzerdefinierten Code ähnlich den Antworten here verwenden und die erforderlichen Parameterwerte entsprechend zurückgeben.

Auf diese Weise können Sie auch verwalten, welche Gruppen von zentraler Stelle aus sehen können, wenn Sie die gleiche Parameterstruktur für alle Berichte eingerichtet haben.

+0

Vielen Dank.Ich entschied mich, einen Parametersatz in eine Konfigurationstabelle zu verschieben, wo je nach der 'Active Directory Gruppe' ein Wert zurückgegeben und als 'Standardwert' verwendet wird. Einige weitere Parameter bleiben in der URL erhalten, da sie das ausgewählte Datum, Costcenter usw. angeben. Für diese Parameter habe ich sichergestellt, dass die "verfügbaren Werte" für den Kontext des Benutzers gültig sind. – Aquillo

Verwandte Themen