Project

General

Profile

Actions

Bug #12546

open

Branch 'Development' - Unit Tests mit dirty workaround angepasst

Added by Carsten Rose almost 3 years ago. Updated almost 2 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Carsten Rose
Target version:
Start date:
14.05.2021
Due date:
% Done:

0%

Estimated time:
Discuss:
Prio Planung:
Vote:

Description

Hallo Marc

Der Develop Branch hat bei mir (webwork16/crose/qfq) diverse Unit Tests mit Fehlern quittiert. Primaer war die URL http://xxxxxxxxxxxxxxxxxxxxxxxxxxxx/qfq/ das Problem.

Ich habe nicht rausgefunden wie sie im gitlab Runner gesetzt wird. Wenn ich die Unit Tests laufen lass steht bei mir http://webwork16.math.uzh.ch/crose/qfq oder der relative Pfad. In den Tests ist als expected aber die genannte URL drin.

Muessen wir wirklich eine zweite hart kodierte URL in dem Test haben? Bis anhin hatten wir www.example.com.

Als Workaround (damit die Tests auf dem gitlab runner und bei mir durchlaufen) gibt es nun eine Konstante BASE_DIR_FAKE die in diversen Tests genutzt wird und teilweise entferne ich zusaetzlich genau die Hostangabe.

Grundsaetzlich sollten wir, wann immer moeglich, keinen Hostnamen angeben.

Vielen Dank

CU
Carsten

Actions #1

Updated by Marc Egger almost 3 years ago

  • Status changed from New to In Progress
Actions #2

Updated by Marc Egger almost 3 years ago

  • Status changed from In Progress to Feedback
  • Assignee changed from Marc Egger to Carsten Rose

Habe dies mit Carsten besprochen.

  • Carsten findet unsere loesung mit den absolut url pfaden koennte probleme machen mit proxy setups.
  • Marc hat auf Stackoverflow gefragt, ob es eine bessere loesung als "absolut url" oder ".htaccess rewrite" gibt.
  • Typo3 controller einzusetzen ist fuer Carsten keine Variante (Gott sei dank).
  • Wir haben uns entschlossen, es bei den absolut urls zu belassen und abzuwarten, ob Probleme auftauchen.

Kopie der Stackoverflow frage und Antworten:

I am a maintainer of the Typo3 extension QFQ.

Our extension accesses many of its files directly by links relative to `index.php` of typo3. For example it requests the following Api file via javascript in the frontend:


> > /typo3conf/ext/qfq/Classes/Api/file.php
> >
> 

Since the upgrade to spoken urls with Typo3 v9 these relative paths stopped working. For example the above relative path would result in the following url when clicked on on in the browser:


> > example.com/en/.../typo3conf/ext/qfq/Classes/Api/file.php
> >
> 

instead of:


> > example.com/typo3conf/ext/qfq/Classes/Api/file.php
> >
> 

We have seen that one can add static routes to single files in the Typo3 backend (Sites > Edit > Static Routes > Create new) but this does not seem to allow us to set the whole extension directory `/typo3conf/ext/qfq` as a static route. Since many files are accessed this way, it is way to tedious to set a static route for every single fie on every installation of Typo3 which uses our extension.

Our own "dirty" solution to this problem would be to add a new rewrite rule to the .htaccess which rewrites any url containing `typo3conf/ext/qfq`. It would remove any path before typo3conf.

My question is: Ist there a better way to solve this problem? How do other extensions create links directly pointing to the files inside the extension directory? Are we missing something obvious?

Thank you

Antwort1:

Common approach in TYPO3 is handling such requests via controller's context and I'd definitely suggest to refactor this instead of accessing files directly. Anyway if for some reason you still want to use standalone scripts, you can just move file in the file structure to some other folder like domain.tld/api/file.php and/or use htaccess to shortcut the URL – biesior 1 hour ago

Antwort2:

It's not recommended to access PHP files inside your extension directly. Use a controller or the Middleware to handle such calls. In a secured environment the direct access to PHP files inside extensions folder is restricted and your extension won't work. – Thomas Löffler 1 hour ago

Actions #3

Updated by Carsten Rose over 2 years ago

  • Target version changed from next3 to next5
Actions #4

Updated by Carsten Rose almost 2 years ago

  • Tracker changed from Support to Bug
Actions

Also available in: Atom PDF