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?
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 –