Missing frontend design and hardcoded paths [self-hosted]

[olpo24]

Hi Stefan,

Describe the bug 1.) It theems the css and js file is not loading. I 've got no idea why.

2.) I read here that different paths are hardcoded. Everthingy what is hardcoded runs in a 404 for me. If I indicate the full path it works. It affects not only the navigation, but also the button "Create api" for example. In which files are hardcoded paths to replace?

[stefanzweifel]

Hi there 👋,

1.) It theems the css and js file is not loading. I 've got no idea why. 2.) I read here that different paths are hardcoded. Everthingy what is hardcoded runs in a 404 for me. If I indicate the full path it works. It affects not only the navigation, but also the button "Create api" for example. In which files are hardcoded paths to replace?

Could you describe, how you've deployed screeenly on your server or how you access it? Does it live on a subdomain (eg. http://screeenly.example.com) or in a sub directory (eg. http://example.org/screeenly)?

If it's on a subdomain, this shouldn't happen, as screeenly uses a lot of absolute paths. I would need more information about how you've setup screeenly on your end.

If it's on a sub-folder: As you correctly pointed out, links in the navigation are hardcoded. If we assume that screeenly has been deployed into a subfolder the root url of screeenly is http://example.org/screeenly/. The link to the "try"-page would then point to http://example.com/try instead of http://example.com/screeenly/try.

As mentioned in the comment, you would have to manually update all links to be relative (eg. /try => try) on your server to make this work.

This is a "mistake" I've made while developing the application many years ago. I'm currently quite busy and don't have the time to update and test the whole application to use relative links. Sorry 😔.

---

I 've got no idea why.

If you're using Chrome, Firefox, Safari or Edge, you could open their Developer Tools and reload the page to see, which requests fail to load. As you've pointed out the CSS file fails to load. Could you paste the full URL which fails to load?

On screeenly.com this looks like this.

---

Does this help to resolve your issue? Let me know if I can help you any further.

[olpo24]

Hi Stefan, thanks for reply.

1.) The CSS an JS runs in an Error 404 too. I suspect that the parmeter id have to be equal to the middle part of the filename app.xxxxxxxx.css ,right? If so, we have the problem. It is different, for CSS an JS. Just seeeing: the css und is loading from domain.tld/css/app.css?id=39da419101d1d391b6d5 But it have to be domain.tld/1/2/3/css/app,css?id

screeenly runs under sub-folder, not sub-domain. So for point 2 of my question so I update the paths to relative.

Best regards Ole

[stefanzweifel]

The id-parameter at the end of the URL is just a random string which is generated for cache-busting (to make sure that always the latest version of the css/js-file is loaded by the browser).

All in all it sounds, that you have to update the navigation links and links to asset-files to be relative.

You have to updated the CSS-path here: https://github.com/stefanzweifel/screeenly/blob/master/resources/views/layouts/_head.blade.php#L10 And the JS-path here: https://github.com/stefanzweifel/screeenly/blob/master/resources/views/layouts/_tail.blade.php#L1

[olpo24]

Servus Stefan,

vielen Dank! CSS und JS funktioniert jetzt.

Und durch die Pfade kämpfe ich mich die Tage durch.

Schönes Wochenende!

[olpo24]

Jetzt muss ich doch nochmal öffnen.

Habe gerade mal die ApI testen wollen:

Symfony \ Component \ HttpKernel \ Exception \ MethodNotAllowedHttpException The GET method is not supported for this route. Supported methods: POST.

screeenly/public/api/v1/fullsize?key=JokDiJXRgJ8EqU6HUK8FZMMYlShSKlrtgSDsdQEpeBKogrwHGd&url=https://google.com

Wo kann ich da ansetzen?

[stefanzweifel]

Wie die Fehlermeldung eigentlich schon sagt, unterstützt die API keine GET-Requests. Nur POST Requests. Da du nun eine eigene Instanz von screeenly am laufen hast, kannst du natürlich frei entscheiden und Dinge anpassen.

Du müsstest diese Zeile zu

Route::get('fullsize', 'v1\ScreenshotController@store')->middleware('auth:api');

anpassen.

[olpo24]

Vielen Dank Stefan, das funktioniert. Noch eine letzte Frage vorerst: Auf Screeenly,com hast du stehen das die Screenhots nach einer Stunde gelöscht werden. Wo kann ich diesen Parameter ändern?

Besten Dank!

[stefanzweifel]

Wo kann ich diesen Parameter ändern?

Das wäre wohl diese Zeile hier: https://github.com/stefanzweifel/screeenly/blob/85e0c5029dde17f8621615ac01679c0b9c1f8ac8/modules/Screeenly/Http/routes/console.php#L7

->subHours(1)

Was in der Selfhosting-Doku gar nicht steht, ist dass der Scheduler eigentlich noch via Cron jede Minute ausgeführt werden müsste. Sie Laravel Dokumentation, wie das eingerichtet werden müsste: https://laravel.com/docs/6.x/scheduling#introduction

Wenn der Scheduler nicht eingerichtet ist, werden Screenshots nicht automatisch nach einer Stunde gelöscht.

[TimoHess]

Ich bekomme auch diesen Fehler nachdem ich probiert habe das Ganze neu aufzusetzen:

Symfony \ Component \ HttpKernel \ Exception \ MethodNotAllowedHttpException The GET method is not supported for this route. Supported methods: POST.

Mehr im Screenshot:

Ebenfalls habe ich es mit einer test.php und dem Aufruf im Browser ausprobiert: Nach diesem Beispiel: https://gist.github.com/stefanzweifel/968e68785277013ac214

Leider kommt nur eine weiße blanke Seite.

Wäre um Hilfestellung echt dankbar. Alles funktioniert, bis auf die benötigte API.

[stefanzweifel]

@TimoHess Du kannst die /fullsize-API nicht direkt im Browser via URL öffnen bzw. triggern. Du musst die Schnittstelle mit einem POST Request ansprechen.

Daher wirft die App auch den Fehler MethodNotAllowedHttpException

The GET method is not supported for this route. Supported methods: POST.

Zum Testen von APIs verwende ich oft ein Tool wie Insomnia. Dann muss ich auch keine test.php-Datei erstellen sondern kann mich auf die API selbst konzentrieren.

Ggf. findest du unter storage/logs in den Log Dateien noch mehr Infos bezüglich der "weissen Seite".

[TimoHess]

Vielen Dank für den Tipp. Mit Insomnia klappt es. Nur komme ich nicht dahin:

Bei mir wird alles angezeigt, incl. .env Konfig. Ich habe APP_DEBUG auf Falsch gestellt und komme nun zu dieser Anzeige:

[stefanzweifel]

@TimoHess Der Fehler auf screeenly.com kommt zustande, da du die URL im Browser aufgerufen hast (nur zur Erklärung warum da nichts kommt).

Aber es geht ja hier um deine Installation (?). Wenn du in deiner Installation APP_DEBUG=false setzt und dann mittels Insomnia einen POST request zu deiner Schnittstelle machst, was siehst du dann? Je nach dem, wie du die Laravel Installation eingerichtet hast, musst du ggf. php artisan config:clear ausführen, sodass die Konfiguration frisch aus der .env-Datei gelesen wird.

Das "Whoops, looks like something went wrong." suggeriert dass es zu einem Serverfehler gekommen ist. Unter /storage/logs/ solltest du eine Log-Datei finden mit viel mehr Informationen zum Fehler.

Die aktuelle Version von screeenly basiert auf Laravel 5.8. Hier wäre die offizielle Dokumentation von Laravel, was der Server alles unterstützen müsste: https://laravel.com/docs/5.8/installation.

Um dich hier mehr zu unterstützen, bräuchte ich viel mehr Infos (was für eine Art von Server; wurden alle PHP und Node Dependencies korrekt installiert etc.)

[TimoHess]

"Der Fehler auf screeenly.com kommt zustande, da du die URL im Browser aufgerufen hast (nur zur Erklärung warum da nichts kommt)." -> Tut mir leid, ich war vorher etwas undeutlich. Das dieser Fehler durch falsches Routing zustande kommt ist mir klar. Die API funktioniert auch mit der Ausgabe von Base64 und in public/storage findet man die Dateien.

Ich benutze Firefox 81.0 und der erste Screenshot zeigt APPDEBUG=true. Der 3. Screenshot mit dem false Wert. Dies sieht vom Aufruf her deutlich anders aus als bei dir, sodass ich zu dem Schluss kam, dass etwas nicht richtig ist. Der 2. Screen zeigt deine API Fehlermeldung mit JSON, Rohdaten und Kopfzeilen._

Selbst im neuen Edge Browser sieht man den Unterschied: Bei dir: {"title":"An error accoured","message":"An internal error accoured."} und bei mir ist es auch dort wie im 3. Screenshot zu sehen:

Ich hoffe meine Unklarheit wurde jetzt eindeutig und klar :)

[stefanzweifel]

Sorry für das hin und her. Mir war einfach nicht ganz klar, was eigentlich das Problem ist, welches dich davon abhält screeenly zu nutzen.

Ich habe die App nun selber kurz gecloned und mittels composer install und php artisan key:generate eingerichtet. Wenn ich in meiner .env den Wert für APP_DEBUG=false setze und mit einem Browser die URL /api/v1/fullsize öffne, sehe ich ich ebenfalls "Whoops, looks like something went wrong.".

Der Unterschied zu screeenly.com kommt durch die Einstellung APP_ENV zustande. Diese wird bei dir local sein. Auf screeenly.com ist der Wert production.

Im ExceptionHandler der App habe ich damals einen Spezialfall eingebaut, das bei einem möglichen Fehler immer ein 400 Fehler mit An internal error accoured. als JSON ausgegeben wird. (Source)

Wenn du bei dir APP_ENV=production setzt und dann die URL im Browser öffnest, siehst du die gleiche Fehlermeldung wie auf screeenly.com.

(Note: Heute würde ich auf keinen Fall mehr so einen Spezialfall einbauen. Das ist völliger Quatsch. Leider hatte ich vor 6 Jahren noch nicht so viel Erfahrung mit API Entwicklung. Laravel war damals auch noch nicht so erwachsen wie heute. Da ich aber nicht die API Implementation von allen Usern mit einer Anpassung kaputt machen will; habe ich das immer so belassen)

---

Klärt das deine Fragen? Dann würde ich im Wiki noch hinzufügen, dass man noch APP_ENV=production in der Kopie setzten müsste.

[TimoHess]

Vielen lieben Dank für die ausführliche Antwort. Das mit dem Spezialfall, dass ein E400 zurückgegeben wird macht da auch irgendwie Sinn. Ich wollte dies einfach aus Performance gründen und der Privatsphäre einfach selber hosten (Nextcloud, private Daten Homecloud, etc....)

Darf ich noch kurz fragen wo der Unterschied zwischen local und production liegt? Einfach nur um es in der Produktion mit einer ordentlichen 400 API Fehlermeldung zurückzuwerfen?

Für deinen Einsatz und die Hilfe hast du Kaffee verdient ;) Note: Laravel, API oder generell PHP sind für mich als noch etwas fremd und steige immer weiter in die Materie ein, momentan bin ich noch bei C#, C++. Also ganz weit weg von WWW-Applikationen.

PS: Auf screeenly.com würde ich eine automatische Weiterleitung auf 443, bzw. SSL (https) einfügen, da viele "Newbies" in dem Bereich den Unterschied zwischen P80 und 443 nicht kennen und ohne Hinweis nicht direkt auf secure.screeenly.com kommen ;) Als kleine Anmerkung bzw. Tipp ;)

PPS: In der Wiki unter Compile assets for production bitte production auf npm run prod umstellen ;)

[stefanzweifel]

Darf ich noch kurz fragen wo der Unterschied zwischen local und production liegt? Einfach nur um es in der Produktion mit einer ordentlichen 400 API Fehlermeldung zurückzuwerfen?

Ich glaube in der App an sich gibt es keine grosser Unterscheidung zwischen local und production. In Laravel gibt es einfach das Konzept von verschiedenen Environments. In anderen Apps nutze ich dieses Environment um zum Beispiel ein Staging System auf Test API zeigen zu lassen.

Mehr Infos dazu: https://laravel.com/docs/8.x/configuration.

Für deinen Einsatz und die Hilfe hast du Kaffee verdient ;) Note: Laravel, API oder generell PHP sind für mich als noch etwas fremd und steige immer weiter in die Materie ein, momentan bin ich noch bei C#, C++. Also ganz weit weg von WWW-Applikationen.

Vielen Dank ❤️ Falls du irgendwann mehr über PHP und insbesondere Laravel lernen möchtest, kann ich dir Laracasts von Herzen empfehlen.

PS: Auf screeenly.com würde ich eine automatische Weiterleitung auf 443, bzw. SSL (https) einfügen, da viele "Newbies" in dem Bereich den Unterschied zwischen P80 und 443 nicht kennen und ohne Hinweis nicht direkt auf secure.screeenly.com kommen ;) Als kleine Anmerkung bzw. Tipp ;)

Danke für den Tipp. Das würde ich eigentlich gerne schon seit 3-4 Jahren machen. Leider hatte in der Vergangenheit eine solche Weiterleitung die API Clients von Usern kaputt gemacht.

In der neuesten (aktuell noch closed-source) Version habe ich den Fehler zum Glück nicht gemacht und HTTPS von Anfang an aktiviert.

PPS: In der Wiki unter Compile assets for production bitte production auf npm run prod umstellen ;)

Fixed.

[TimoHess]

Vielen Dank mit dem Laracasts Tipp.

Zur Weiterleitung: Du könntest mit certbot (nehme ich mal an, da du auch letsencrypt benutzt ;) ) wildcards erstellen, z.B. sudo certbot --apache -d screeenly.com -d www.screeenly.com -d secure.screeenly.com Und die Weiterleitung nur von screeenly.com vornehmen. Ich denke dies könnte klappen. secure.screeenly lässt du einfach beim alten ;). So hast du mit einem Zertifikat 3 Fliegen mit einer Klappe geschlagen ;)

Oder du führst nur im Loginbereich SSL ein, damit zumindest Nutzerpasswörter sicher sind ;)