View Issue Details

IDProjectCategoryView StatusLast Update
0003355OXID eShop (all versions)6. ------ Setup -------public2015-09-10 15:25
Reporterray 
PriorityurgentSeverityblockReproducibilityhave not tried
Status resolvedResolutionsuspended 
Product Version4.5.4 revision 39463 
Target VersionFixed in Version 
Summary0003355: mod_rewrite vs. .htaccess
DescriptionPlease check again the issue from https://bugs.oxid-esales.com/view.php?id=1353 as it seems to be back in actual version.

See thread here:
http://www.oxid-esales.com/forum/showthread.php?t=1262&page=3#post72511
TagsNo tags attached.
ThemeBoth
BrowserAll
PHP Versionany
MySQL Versionany

Relationships

related to 0001353 resolveddainius.bigelis mod_rewrite test in setup fails when shop base folder is protected with htaccess 
related to 0005513 acknowledged mod_rewrite module check fails when protecting shop via htaccess & htpasswd 

Activities

DSB

2011-11-06 11:26

reporter   ~0005367

The problem is:
if you protect the shop folder using auth via .htaccess the setup screen complains about missing mod_rewrite (and won't let the user continue the setup process)!
This is incorrect because the method checkModRewrite() in oxsysrequirements.php sends a POST-request against oxseo.php and checks if the response has the string "mod_rewrite_on" in it.
While the requests runs against the authentification it doens't have that string. Nevertheless mod_rewrite might be present.

Best solution: check returned http status code to identify required auth, let the user input the username and password and request again using auth.

5 minute fast solution: add a text output to installation screen, telling the user that he has to disable any authentification while running the setup.

FibreFoX

2011-11-17 20:27

reporter   ~0005398

another fast solution without modifying giant amount of code would be a tiny redirect-rule for this test. something like "mod_rewrite_check.php?passed=false" that is rewritten with a tiny rule to "mod_rewrite_check.php?passed=true", maybe this can be used for the whole test.
at setup-process it can be the first step that is tested/redirected ... if its not redirected there is no mod_rewrite.

another method would be an additional way to detect:
http://de3.php.net/manual/en/function.apache-get-modules.php

DSB

2011-11-17 22:17

reporter   ~0005399

>>another fast solution without modifying giant amount of code would be a tiny redirect-rule for this test. something like "mod_rewrite_check.php?passed=false" that is rewritten with a tiny rule to "mod_rewrite_check.php?passed=true", maybe this can be used for the whole test.

This wouldn't change anything if your shop folder is protected via .htaccess, see my description above. Oxid is doing it this way and that is the cause of the problem.

>>another method would be an additional way to detect:
http://de3.php.net/manual/en/function.apache-get-modules.php

This check only works for Apache. Some people don't run Oxid on Apache but e.g on Nginx. I don't think this is a good idea. ;)

Arunas

2011-11-24 15:33

reporter   ~0005445

Last edited: 2011-11-24 15:43

View 2 revisions

The best solution at this time is just to add.:
Order Deny,Allow
Deny from All
AuthType Basic
AuthName "Protected"
AuthUserFile /eshop/.htpasswd
Require valid-user
Allow from localhost #hostname where the shop is
Satisfy Any

In this scenario all the request from the same server (localhost) will IGNORE
the Authentification and allow for mod_rewrite to change the request.

Added a comment to the beggining of the .htaccess file of how to correctly
add .htpasswd

marco_steinhaeuser

2011-11-29 00:15

administrator   ~0005450

Re-opened this bug.
As this has been a discussion and an issue for a while, please talk to me. Maybe next week in Freiburg should be a good chance ;)

FibreFoX

2011-11-29 12:40

reporter   ~0005452

@DSB
maybe i was misinterpreted, i'll try to explain it later (i ment a redirect to the check-page, because if rewrite is active a parameter is set, otherwise not)

dainius.bigelis

2011-12-28 11:09

reporter   ~0005532

In some future versions it's planned to rebuild the setup in general and improve some parts, including the system requirements check and this case also.
So until then this entry is suspended (we have reference to that inserted in out internal backlog).
Thanks for your feedback.