errorMessage mit Exception-Text?

[Lednerb]

Beim Scan mit Connection Error wird einfalsches Format ausgegeben:

{
    "name": "CMSVERSION",
    "version": "1.0.0",
    "hasError": true,
    "errorMessage": "cURL error 28: Resolving timed out after 5516 milliseconds (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)",
    "score": 0,
    "id": 3
  }

errorMessage muss vom Typ TranslatableMessage sein, um dem Standard zu entsprechen.

[SniperSister]

Fixed, bitte prüfen

[Lednerb]

@SniperSister

Ich verstehe den Ansatz, die EXCEPTION_MESSAGE mit zu speichern. Allerdings glaube ich nicht, dass wir diese dem Nutzer übersetzen werden. Daher könnte man sich den Eintrag der placeholders sparen.

@Skeeve was denkst du dazu?

{
  "name": "CMSVERSION",
  "version": "1.0.0",
  "hasError": true,
  "errorMessage": {
    "translationStringId": "INTERNAL_ERROR_OCCURED",
    "placeholders": {
      "EXCEPTION_MESSAGE": "cURL error 28: Resolving timed out after 5517 milliseconds (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)"
    }
  },
  "score": 0
}

[Skeeve]

Also deutsch: INTERNAL_ERROR_OCCURED=Es ist ein interner Fehler aufgetreten. Die Meldung lautet: ":EXCEPTION_MESSAGE".

Englisch: INTERNAL_ERROR_OCCURED=An internal error occured. The message is:: ":EXCEPTION_MESSAGE".

Oder?

[Lednerb]

Korrekt, aber wollen wir dies auch dem Nutzer anzeigen, dass wir einen curl-Error haben?

[Skeeve]

Könnte u.U. hilfreich sein.

Alternative: Für jede Exception eine UUID generieren. Mit dieser UUID und einem defnierten "Marker" ins LOG schreiben und melden:

Es ist ein Fehler aufgetreten. Der Administrator wurde benachrichtigt. Fehlercode :UUID

Anhand des Markers können wir solche Exceptions schnell finden und rückfragenden Nutzern helfen. Gegebenenfalls auch angand des Markers monitoren.

[Lednerb]

Alternative: Für jede Exception eine UUID generieren. Mit dieser UUID und einem defnierten "Marker" ins LOG schreiben und melden:

Es ist ein Fehler aufgetreten. Der Administrator wurde benachrichtigt. Fehlercode :UUID

Anhand des Markers können wir solche Exceptions schnell finden und rückfragenden Nutzern helfen. Gegebenenfalls auch angand des Markers monitoren.

Nein, wir beziehen uns hierbei auf die Scanner, die eine externe Entwicklung sind und die wir nicht verpflichten sollten soetwas einzubauen. Es gibt das genannte Nachrichtenformat und dort sollen leicht verständliche Nachrichten für unsere Zielgruppen geliefert werden.

Momentan sehe ich keinen Mehrwert für KMUs darin, bspw. einen englischsprachrigen curl-Fehler auszugeben.

[Skeeve]

"Momentan sehe ich keinen Mehrwert für KMUs darin, bspw. einen englischsprachrigen curl-Fehler auszugeben" Jein. Einige der Curl Fehlermeldungen könnten hilfreich sein: z.B. Nr. 7, 8, 9, 22, 28, 35(?), 47, 52, 60 https://curl.haxx.se/libcurl/c/libcurl-errors.html

Wenn man die abfängt und dem Kunden mitteilt (z.B. für 60) "Ihr Server hat ein ungültiges SSL Zertifikat geliefert", könnte das in der Fehlersuche hilfreich sein.

Ein MUSS das zu liefern sollte es aber nicht geben.

[SniperSister]

Spricht was dagegen es vom Scanner returnen zu lassen, dann aber in der BLA den Placeholder zu ignorieren? Der Scanner kann somit im Standalone sinnvolles Feedback geben.

[Skeeve]

Placeholder dürfen auch ignoriert werden.

[Lednerb]

Spricht was dagegen es vom Scanner returnen zu lassen, dann aber in der BLA den Placeholder zu ignorieren? Der Scanner kann somit im Standalone sinnvolles Feedback geben.

Das funktioniert, setzt aber voraus, dass der genutzte Placeholder dann nicht im Text verwendet wird. Insofern eine sehr gute Lösung, die ich auch befürworten würde.

Also konkretes Beispiel:

Nachricht:

"errorMessage": {
    "translationStringId": "INTERNAL_ERROR_OCCURED",
    "placeholders": {
      "EXCEPTION_MESSAGE": "cURL error 28: Resolving timed out after 5517 milliseconds (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)"
    }
  },

INTERNAL_ERROR_OCCURED: Ihre Seite konnte nicht gescannt werden.

(Nachricht ohne :EXCEPTION_MESSAGE)