Skip to main content

SecurityException bei Auftrag in neuem Thread

Comments

5 comments

  • Zendesk API User
    Author: boersteken - 5/28/2018 12:27

    Hallo Robin,

    es kann sehr gut sein, dass innerhalb so großer Versionssprünge irgendwann ein Security-Check implementiert wurde, der mit eurer Anforderung clashed. Trotzdem ist dies ein Fehlzustand und ich vermute, dass es sich hierbei um einen Bug handelt. Wende dich daher bitte an unseren Technical Support FirstSpirit Technical Support.

    Grüße,

    Philipp

    0
  • Zendesk API User
    Author: robin_kump - 5/28/2018 13:05

    Hallo Philipp,

    danke für das Feedback. Anfrage ist erstellt.

    Wenn es ein relevantes Ergebnis gibt, ergänze ich das hier.

    Beste Grüße

    Robin

    0
  • Zendesk API User
    Author: SHeinrich - 7/6/2018 11:48

    Hallo,

    wir haben aktualisiert von 5.2 R21 FS auf 5.2.2109.77244 und bekommen den gleichen Fehler.

    Gibt es "best practise" beim Hinzufügen von Startknmoten bei einem Auftrag?

    Auszug:

    List startNodes = st.getStartNodes();

    startNodes.add(newPageRefForXml);

    Fehler: java.lang.SecurityException: CHANGE_PROJECT

    Gruß,

    S. Heinrich

    0
  • Zendesk API User
    Author: mscholz3 - 7/6/2018 12:14

    Hallo Robin,

    nach dem Update auf R20 konnten wir Aufträge auch nicht mehr per Code manipulieren und hatten auch eine Security bzw. eine Berechtigungs-Fehlermeldung erhalten.

    Nachdem wir den Benutzer bzw. die Gruppe in "Interaktiven Ausführung" hinzugefügt haben, hat es wieder funktioniert. Beispiel:

    Vielleicht hilft das ja.

    Liebe Grüße

    Marcel

    0
  • Zendesk API User
    Author: robin_kump - 7/6/2018 12:55

    Hallo Marcel,

    danke für den Hinweis.

    Die entsprechenden Gruppen waren bei uns schon im Auftrag hinterlegt. Das Problem hat es bei uns leider trotzdem gegeben.

    Zwischenzeitlich hatte ich auch regen Kontakt mit dem Support. Ergebnis: Das liegt an einem neuen Security-Modell.

    Die Methode setActive(), mit der man einzelne Tasks aktivieren kann, darf von einem normalen User nicht mehr ausgeführt werden. Das Modell scheint aber noch etwas löchrig zu sein (meine Ansicht), da das in vielen Fällen eben doch noch möglich ist.

    Die Empfehlung lautet die Logik zum aktivieren einzelner Tasks in einen zusätzlichen Task zu verschieben, da der Auftrag im Kontext des System-Users läuft und dieser die nötigen Rechte besitzt.

    Es gibt auch einen Feature-Switch, um die Logik vorübergehend auf den alten Mechanismus zurück zu stellen. Ich möchte dem Support aber nicht in den Rück fallen und verzichte daher hier auf die Nennung des konkreten Switchs. Bei Bedarf bitte beim Support melden.

    Wir haben uns Ende dieser Woche dazu entscheiden alle unsere betroffenen Aufträge umzubauen. Aber wahrscheinlich keine zusätzlichen Script-Tasks, da die aus unserer Sicht ganz schlecht zu entwicklen und warten sind, sondern komplett eigene Module oder Executables.

    Viele Grüße

    Robin

    0

Please sign in to leave a comment.