Beiträge von Patrick0815

Zitat von Bud

Gibt es bei Strota so etwas wie einen Inhaberwechsel, und hat dort noch jemand einen alten VC1-1 den er nicht mehr benötigt?

Spoiler anzeigen

Habe demnächst einen Rubber Ducky in NUE abzugeben – braucht jemand einen?

Es gibt soweit ich gesehen habe eine Möglichkeit den Vertrag zu übertragen.

Ich habe einen VPS Entry Linux VC2-4 den ich abgeben könnte.

Zitat von FelixSocke

Ich sehe bei den Versionen nicht ganz durch. Ich habe doch die 4.0 angegeben? Die 4.3.5 funktioniert nicht. Ich habe dafür halt ein Turtorial von Netcup selber genommen, angeblich zuletzt aktualisiert vor einem Jahr. Leider stehen dort noch ältere Versionen...

Die Versionen findest du hier: https://github.com/SamKirkland/FTP-Deploy-Action

Hab mich vorhin verlesen und in deinem Codeschnipsel ein v2 gesehen, sorry.

Die v4.0.0 ist auch schon ziemlich alt, was klappt denn bei der 4.3.5 nicht?

Vielleicht hilft dir ja: https://github.com/SamKirkland/FTP-Deploy-Action/issues/192 und https://github.com/SamKirkland/FT…ment-1673954975

Ich nutze die FTP Action von Sam Kirkland selbst,

allerdings in einer wesentlich neueren Version, aktuell ist 4.3.5, die v2 ist von 2019.

Aktualisiere am Besten mal die Version und schau ob es dann klappt.

Bist du bei dem Thema weitergekommen?

Ich kann dir ansonsten gerne mal eine Testfunktion auf AWS zur Verfügung stellen, mit der du die Integration testen kannst.

export const handler = async (event) => {
  
  const method = event.httpMethod;
  const body = JSON.parse(event.body);
  var returnData = 'Hello from Lambda!';
  
  switch (method) {
    case 'OPTIONS':
      returnData = 'Hello from Lambda: OPTIONS';
      break;
    case 'POST':
      returnData = {
        message: 'Hello from Lambda: POST',
        receivedData: body
      };
      break;
    default:
      break;
  };
  const response = {
    statusCode: 200,
    body: JSON.stringify(returnData),
  };
  return response;
};

Endpunkt würde ich per PM teilen (aus Gründen )

Alleine das mit Postman wieder ein 404 zurückkommt inkl. „Not found“ ist ein starker Hinweis das der Aufruf nicht in deiner Java Lambdafunktion ankommt.

Woran es liegt ist aus der Ferne schwer zu beurteilen.

Bau doch testhalber mal eine API ähnlich wie mein Beispiel mit z.B node auf und schau ob du damit zum Erfolg kommst.

Gibt es eigentlich einen Grund Java zu verwenden und keine Laufzeitumgebung wie node oder Python?

Das wird ja immer schlimmer

Ich denke wir sollten noch einmal ein paar Dinge zurückbauen und die Grundfunktionen testen.

Deine Lambda Funktion inkl. des Endpoints solltest du erstmal über eine Tool wie z.B. Postman testen, ob sie auch wirklich tut was du möchtest.

Du einen direkten Aufruf kannst du das CORS Thema erstmal umgeben.

Ich habe mir mal Beispielhaft eine Lambda Funktion erstellt und teste diese mittels Postman.

Lambda Funktion

pasted-from-clipboard.png

Im API Gateway (http api) ist nur eine Route definiert.

pasted-from-clipboard.png

CORS ist ebenfalls konfiguriert

pasted-from-clipboard.png

Wichtig ich nutze keine Authorization, etc.

Bevor ich die Funktion nun so benutze wie sie aus dem Frontend aufgerufen wird, teste ich sie ohne CORS Headers.

Es wird dabei direkt eine POST Request erzeugt.

pasted-from-clipboard.png

Nun der nächste Test um die CORS/OPTIONS Funktionalität zu prüfen.

pasted-from-clipboard.png

Im CORS Test setze ich zusätzliche Header (vglb. Frontend), wie man sieht fügt AWS beim Response die entsprechenden CORS Header hinzu (die Lambda Funktion ergänzt hier nichts).

Ich kann dir daher nur empfehlen auf die Basic zurückzukehren und mit einer Route zu starten.

Den POST Request würde ich mit geeigneten Daten dann erstmal unabhängig zum Frontend testen (siehe mein POST Request), sollte hier alles klappen geht es weiter mit OPTIONS (hier sollte es ausreichen in deiner Funktion bei OPTIONS einfach einen Status 200 zurückzusenden.

Aktuell sieht es für mich so aus, als ob die neue "/{proxy+}" Route nicht mit deinem Lamda Handler verknüpft ist (keine Integration)

Diese Aussage mache ich aufgrund dieses Codeblocks:

...
if ("POST".equals(httpMethod) && "/Kontakformular-Emailversand".equals(path)) {
    response = handlePostRoute(request);
 } else if ("ANY".equals(httpMethod) && path.startsWith("/proxy")) {
    response = handleProxyRoute(request);
 } else {
    response.setStatusCode(404);
    response.setBody("{\"message\":\"Route not found\"}");
 }
...

In der Browserkonsole sehen wir im Preflight einen OPTIONS Request, diese sollte damit im else Zweig landen und damit einen Status Code 404 zurücksenden (inkl. Body "Route not found)", dies passiert aber nicht es kommt ein 204 ohne Body zurück.

Nehme wir mal an die Funktion wäre korrekt verknüpft, möchtest du die notwendigen Header eigentlich im else if behandeln, dies wird m.E. aber nicht funktionieren da die Methode OPTIONS und nicht ANY ist.

Selbst wenn der Vergleich funktionieren sollten, sollten wir einen Status Code 200 sehen (inkl. Body "Proxy route handled successfully")

Die auskommentierte Methode getCORSHeaders wird auch nicht dazu beitragen, die richtigen Header an den Browser zurückzusenden.

Stelle sicher das die neue Route auch in deiner Lamda Funktion landet, dann sollte das CORS Problem auch lösbar sein.

Zitat von Patrick0815

Hast du der Default Route auch eine Funktion hinterlegt?

Ich beantworte es mir mal selbst, es sieht nicht danach aus, ansonsten sollten diese in den Response Headers auftauchen.

pasted-from-clipboard.png

Diese oder ähnliche hätte ich im Response erwartet.

statusCode: 200,
headers: {
 "Access-Control-Allow-Headers" : "Content-Type",
 "Access-Control-Allow-Origin": "https://www.example.com",
 "Access-Control-Allow-Methods": "OPTIONS,POST,GET"
 },

Leider enthält keiner der Screenshots die gesendeten Header (Response, Reply)

Hast du der Default Route auch eine Funktion hinterlegt?

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

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

export const handler = async (event) => {
    const response = {
        statusCode: 200,
        headers: {
            "Access-Control-Allow-Headers" : "Content-Type",
            "Access-Control-Allow-Origin": "https://www.example.com",
            "Access-Control-Allow-Methods": "OPTIONS,POST,GET"
        },
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

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

Funktioniert dein Kontaktformular nun?

Leider sind beide Screenshots/Attachments nicht im Beitrag vorhanden.

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

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.

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

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/questions/7618…lambda-function

Der essentielle Teil ist hier dokumentiert: https://docs.aws.amazon.com/apigateway/lat…s-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.

Zitat von Alusch

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.

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.

Sei so gut und kopiere auch die aktuellen Fehlermeldungen in den Beitrag.

Du hast nun exakt einen spezifischen Host von AWS erlaubt: https://s52tbcrlt5.execute-api.eu-central-1.amazonaws.com

Sicher das alle Lambafunktionen von s52tbcrlt5 ausgeführt werden?

Mein ursprünglicher Vorschlag war https://*.execute-api.eu-central-1.amazonaws.com

Nur auf die Schnelle überflogen, im Prinzip musst du dich an diese Anleitung halten.

https://www.mailerlite.com/help/how-to-add-a-custom-domain-to-landing-pages-and-websites

Was nicht funktionieren wird ist es die Seite auf http://www.vorname-nachname.de/newsletter umzubiegen.

Falls du unter der Domain planst noch weitere Inhalte anzubieten, wäre es möglich eine Subdomain zu nutzen https://newsletter..vorname-nachname.de

Maillite zeigt dir die notwendigen Einstellungen im DNS dazu an.

Bezieht sich dein Problem auf die DNS Einstellungen im CCP?

Hast du für den TXT Record auch nur _dnsauth im Feld hinterlegt? example.com wird automatisch ergänzt.

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.

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.

FileZilla gibt normalerweise mehr Logginginformationen aus, in denen auch ein Hinweis steht warum die Verbindung nicht aufgebaut werden konnte.

Kannst du diese teilen?

Ansonsten sind die Gründe vielfältig von falscher Port, Zertifikatsfehler, yyy

Zitat von HAL9000

Ich hoffe, dass ist kein Zeichen davon, dass sich netcup in den nächsten Jahren auflösen möchte und keinen Sinn mehr darin sieht das noch rauszunehmen.

Glaube ich selbst jetzt eher nicht.. aber wer weiß?

Dem wird sicher nicht so sein.

Da Netcup auf Plesk setzt sind dem Customizing der einzelnen Instanzen Grenzen gesetzt.

Per Default laufen Dienste wie Mail, DNS, Web und Datenbank in die gleiche Oberfläche rein.

Netcup geht hier einen etwas anderen Weg, so dass die eine oder andere Checkbox eben keine Funktion hat, da der zugehörige Service woanders läuft.