Nutzung von AWS Lambda für Backendoperation auf Website

  • Product: Hosting195801 - Webhosting 1000 NUE

    Guten Tag,

    ich nutze das oben angegebene Produkt von netcup für meine Website. Bisher hatte ich nur statische Inhalte auf meiner Seite - also nur das Frontend in Nutzung. Das hat alles funktioniert.

    Nun möchte ich aber eine serverless function mit AWS Lambda nutzen, um für ein Kontakformular auf meiner Seite die entsprecehnde Funktionalität bereitzustellen.

    Aktuell erhalte ich beim Versuch, die Lambda-Funktion per Buttonklick unter dem Formular auszulösen, einen CORS-Fehler. Nachdem ich nun schon einiges probiert habe in den CORS-Einstellungen bei AWS Lambda und in der Backend-Datei, möchte ich hier mal nachfragen.

    Kann es sein, dass ich mit meinem Netcup-Produkt gar keine Backendoperationen ausführend kann?
    Muss ich vielleicht hier im Control Panel irgendetwas konfigurieren, um den CORS-Fehler zu beseitigen?

    Vielen Dank für etwaigen Rat
    Beste Grüße

  • Besten Dank Patrick für deine Rückmeldung.

    Wenn ich auf meiner Domain die Funktion zum Versand des Kontaktformulars auslösen möchte, erhalte ich:

    Code
    Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf https://s52tbcrlt5.execute-api.eu-central-1.amazonaws.com/default/Kontakformular-Emailversand. (Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt). Statuscode: 204.
    
    Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf https://s52tbcrlt5.execute-api.eu-central-1.amazonaws.com/default/Kontakformular-Emailversand. (Grund: CORS-Anfrage schlug fehl). Statuscode: (null).
    
    
    Fehler beim Emailversand (Object { headers: {…}, status: 0, statusText: "Unknown Error",....)
    
    
    [tt][tt][/tt][/tt]




    Code
    Es natürlich auch sein, dass die Cors-Fehler nur ein Symptom des "Fehlers beim "Emailversand" sind und dort die eigentliche Ursache liegt. Ich prüfe gerade in beide Richtunge
  • Das sieht nach einem SOP Problem aus, Access-Control-Allow-Origin fehlt und sollte gesetzt werden, z.B. auf https://*.execute-api.eu-central-1.amazonaws.com


    Was nutzt du für ein Frontend?


    Am einfachsten wird es wohl sein den fehlenden Header über Plesk auszuliefern:

    https://stackoverflow.com/questions/24930931/how-to-enable-cors-on-plesk-11-5


    Zu finden unter „Einstellungen Webserver“: https://helpcenter.netcup.com/de/wiki/webhosting/interface

    Bitte den nginx-Proxymode beachten.


  • Das klingt doch etwas anspruchsvoll. Aber ich versuche das natürlich.

    Mein Frontend habe ich mit Angular erstellt. Die Lambda-Funktion habe ich in Java geschrieben.

  • Das klingt doch etwas anspruchsvoll. Aber ich versuche das natürlich.

    Im ersten verlinkten Artikel ist es recht gut beschrieben.

    Nehmen wir man du nutzt den nginx-Proxymodus, dann fügst du einfach folgende Zeile hinzu:


    Code
    add_header Access-Control-Allow-Origin https://*.execute-api.eu-central-1.amazonaws.com/;
  • CORS in Lamda und die zusätztliche Header in Apache:

    1a) https://imgur.com/a/q5WX2oI

    1b) https://imgur.com/a/HPtRNEN

    2) https://imgur.com/a/oRNUwdU

    Das Feld "zusätzliche Nginx-EInstellungen" (wie im stackoverflow-Beitrag) gibt es in den Einstellungen in Netcups bei mir nicht. (Screenshot 3)
    Da Nginx als Proxy fungiert, werden Anfragen anscheinend an Apache weitergeleitet (SH 2). Daher habe ich die Header dort eingetragen (SH 1)
    Ich habe versucht Lambda-CORS-Einstellungen damit zu synchronisieren.

    In der Backend-Datei habe ich die Methode zum Header hinzufügen entfernt.

    Das Resultat bleibt leider das Selbe.



    Quote

    Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf https://s52tbcrlt5.execute-api…ntakformular-Emailversand. (Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt). Statuscode: 204.

    Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf https://s52tbcrlt5.execute-api…ntakformular-Emailversand. (Grund: CORS-Anfrage schlug fehl). Statuscode: (null).

    Fehler beim Emailversand Object { headers: {…}, status: 0, statusText: "Unknown Error", url: "https://s52tbcrlt5.execute-api.eu-central-1.amazonaws.com/default/Kontakformular-Emailversand", ok: false, name: "HttpErrorResponse", message: "Http failure response for https://s52tbcrlt5.execute-api…takformular-Emailversand: 0 Unknown Error", error: error }

  • Screenshots bitte direkt im Beitrag einfügen und nicht über externe Dienste gehen.


    Leider sehen wir nicht was du nun als Allow-Origin eingetragen hast.

    Die Debugkonsole meckert weiterhin über den fehlenden Header, hast du mal auf dem Netzwerk-Tab der Developertools geschaut ob die eingestellten Header auch im Browser ankommen.

  • Hab mir das ganze gerade mal mit curl angeschaut, der Hostname war im Screenshot einsehbar.


    Bei den allowed origins gehört natürlich AWS rein und nicht der eigene Hostname


    Du willst erreichen, dass Inhalten von AWS zusätzlich vertraut wird und nicht nur dem eigenen Host.

  • Screenshot 2024-09-04 014612.png

    Entspricht das deinem Vorschlag?


    Dadurch ändert sich beim Versuch die Lambda-Funktion auf meiner Website aufzulösen leider nichts. Ich erhalte die gleichen drei Fehlermeldungen wie zuvor (Zweimal Cors, Fehler bei Emailversand).


    Der Allow-Origin-Header im Lambda Cors scheint zu passen, sonst hättest du dazu wohl noch kommentiert.


  • Der Allow-Origin-Header im Lambda Cors scheint zu passen, sonst hättest du dazu wohl noch kommentiert.

    Ich hatte mir den noch nicht genauer angeschaut, aber du scheinst da ein www. vor deine Domain gepackt zu haben, die Seite schickt aber von https://example.com (ohne www).


    Der geworfene Fehler in der Browserkonsole bestätigt dies auch, nun ist der Fehler im der Lambdakonfig zu suchen.


    Code
    Access to XMLHttpRequest at 'https://s52tbcrlt5.execute-api.eu-central-1.amazonaws.com/default/Kontakformular-Emailversand' from origin 'https://example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
  • Das sind meine aktuellen Werte in Apache (s. 1.). Ich möchte nur diese eine Funktion für den Mailversand im Lambda ausführen (s. 2.).

    Beim Speichern neuer Wert in Apache auf netcups kommt der Hinweis: [[willBeAppliedAfterApacheRestartInterval]]
    Ich habe mit einer Dateiänderung im Netcup-Dateimanager einen Neustart versucht auszulösen und noch einige Stunden vergehen lassen.

    Mit dieser Einrichtung erhalte ich dennoch die gleichen Fehler wie zuvor (s.3).

    Besten Dank für deine Ausdauer.

    1.

    forum.netcup.de/system/attachment/13463/ 


    2.
    forum.netcup.de/system/attachment/13466/

    3.

    Quote

    Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf https://s52tbcrlt5.execute-api…ntakformular-Emailversand. (Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt). Statuscode: 204.

    Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf https://s52tbcrlt5.execute-api…ntakformular-Emailversand. (Grund: CORS-Anfrage schlug fehl). Statuscode: (null).

    Fehler beim Emailversand

    Object { headers: {…}, status: 0, statusText: "Unknown Error", url: "https://s52tbcrlt5.execute-api…ntakformular-Emailversand", ok: false, name: "HttpErrorResponse", message: "Http failure response for https://s52tbcrlt5.execute-api…takformular-Emailversand: 0 Unknown Error", error: error }

  • Leider sind beide Screenshots/Attachments nicht im Beitrag vorhanden.


    Die CORS Settings in deinem Frontend scheinen aber zu passen, den von dir gezeigten Fehler

    Code
    Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf https://s52tbcrlt5.execute-api…ntakformular-Emailversand. (Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt). Statuscode: 204.

    kann ich nicht mehr nachvollziehen.


    Deine Seite liefert u.a. die folgenden Header aus.

    Code
    access-control-allow-origin: https://*.execute-api.eu-central-1.amazonaws.com
    access-control-allow-methods: GET, POST, OPTIONS
    access-control-allow-headers: Content-Type, Authorization, X-Requested-With
    accept-ranges: bytes

    Nutze ich dein Kontaktformular, sehe ich nur noch den folgenden Fehler

    Code
    Access to XMLHttpRequest at 'https://s52tbcrlt5.execute-api.eu-central-1.amazonaws.com/default/Kontakformular-Emailversand' from origin 'https://example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

    Was auf eine Fehlkonfiguration bei AWS oder einen fehlerhaften Request hindeutet.


    Ist auf AWS Seite auch https://example.com für Access-Control-Allow-Origin gesetzt, im Beitrag #8 steht hier noch ein www davor.

    Ein weiteres Problem ist vermutlich, dass du dir noch eine Route für Lambda fehlt, da du einen Authorizer verwendest.

    Auf die schnelle recherchiert, könnte das hier noch dein Problem sein https://stackoverflow.com/ques…teway-and-lambda-function

    Der essentielle Teil ist hier dokumentiert: https://docs.aws.amazon.com/ap…tp-api-cors-default-route


    Wichtig:

    Da bei dir noch der ursprüngliche Fehler angezeigt wird, hast du auch mal den Browsercache geleert oder auf eine Inkognitotab gewechselt, du scheinst noch mit alten Daten zu arbeiten.

  • Hallo Patrick,

    sorry, ich war bis gestern auf einer Radtour und ohne Laptop unterwegs, Und diese Angelegenheit lässt sich nicht über das Handy regeln.
    Ich werde das morgen wieder angehen und mich hier melden. Danke der Nachfrage.

  • Deine neue Default Route schickt aber auch was zurück?

    Auf der Konsole wird im Preflight weiterhin der fehlende Header bemängelt.


    Zeig mal die Requests/Responses aus dem Netzwerktab der Entwicklerkonsole.