<?php
preg_match("~.php$~", $_SERVER["REQUEST_URI"])
? include ltrim($_SERVER["REQUEST_URI"], "/")
: http_response_code(404);
?>
Apache kunt niet mijnGeheimScript.php vindt (404) -> proxy.php is niet verzoekt vanuit externe dus geen $_POST | $_GET | $_REQUEST variable(s) zijn gecreëerd :( maar wel draaid mijnGeheimScript.php
Zoals je hierboven in het schema kunt lezen worden alle url's doorgestuurd naar index.php, het enigste php bestand in je webroot.
In dit index.php bestand doe je slechts een paar kleine simpele dingetjes. Alle andere php bestanden staan buiten je webroot.
Het heeft niets te maken met POST of GET of AJAX.
Een framework biedt je alles waar je nu om roept in dit draadje
onder andere:
- single point entry
- clean url's
- directory structuur
- tal van additional modules voor allerlei doeleinden
- een schat aan libraries
[size=xsmall]Toevoeging op 05/01/2017 16:31:06:[/size]
GOOGLE ook eens op MVC...
?
Onbekende gebruiker
05-01-2017 16:33
gewijzigd op 05-01-2017 16:36
Heeft als met AJAX te maken.
'gewoon' URL verzoek (Chrome Inspector):
Request URL:https://acer-ubuntu:4443/WM_3.html
Request Method:GET
Status Code:200 OK
Remote Address:192.168.2.11:4443
'gewoon' AJAX verzoek vanuit WM_3.html (Javascript):
Request URL:https://acer-ubuntu:4443/validateAccountName.php
Request Method:POST
Status Code:204 No Content
Remote Address:192.168.2.11:4443
Ik heb moeite om je te volgen dus misschien moet je je probleem wat beter omschrijven?
Maar er is een verschil tussen afgeschermde mappen IN of hoger dan je WEBROOT en bestanden BUITEN je webroot he?
Stel je webroot is:
/var/www/example.com/public_html (Je index.php is dus: /var/www/example.com/public_html/index.php)
Dan is dit een voorbeeld van een afgeschermde map:
/var/www/example.com/public_html/php ( in de php map staat dan een .htaccess met de inhoud 'Deny from all')
En dit is een voorbeeld van een map buiten je webroot:
/var/www/example.com/private (Hier kun je met het http protocol zowiezo niet komen)
'Deny from all'? Waar? In {DOCUMENT_ROOT}/.htaccess? De AJAX verzoek aan de script krijgt HTTP 403 (en gewoone URL verzoeken, ook).
Stel je dat scripts liggen in {DOCUMENT_ROOT}/PHP/ met een .htaccess inhout 'Deny from all'. Nu krijgt de verzoek HTTP 404. Of je de pad vanuit de Javascript aanpassen tot '/PHP/validateAccountName.php' is de AJAX verzoek: https://acer-ubuntu:4443/PHP/validateAccountName.php en krijgt de verzoek HTTP 403.
Toegang te scripts, wat liggen buiten DOCUMENT_ROOT door een script (proxy.php) dat woont in DOCUMENT_ROOT krijgt HTP 200.
Waarom gebruik je jouw oplossing (welke problemen lost dit op)? Motivatie? Want ik kan je (oplossingsrichting) eerlijk gezegd niet echt volgen.
Waar loop je tegenaan (oorspronkelijke bericht: je mist superglobals)? Heb je een concrete vraag?
Wie heeft je in hemelsnaam verteld dat een andere aanpak "onveilig" zou zijn? Kun je ook uitleggen waarom het onveilig zou zijn? Indien het gaat om het voorkomen van rechtstreekse aanroepen van bepaalde scripts: daar zijn ook andere, en wellicht makkelijkere, oplossingen voor.
?
Onbekende gebruiker
05-01-2017 18:51
Ik wil niet de IP binnen de scripts openbaar te maken. Ook niet de mappen structuur van de toepassing (ingezien van JavaScript / AJAX verzoeken). Zo, buiten DOCUMENT_ROOT moeten PHP scripts zitten.
En, ik wil graag andere, makkelijkere oplossingen te horen.
Je kunt de internetkabel uit je server trekken, dan heb je geen lekkage meer ;-)
Wat ik bedoel te zeggen:
Natuurlijk wil je bepaalde gegevens niet laten lekken maar wat jij doet is heel je huis met rolluiken beveiligen behalve de garagedeur welke je vervolgens vergeet in het slot te draaien.
Mag ik vragen wat die proxy.php doet. Krijg altijd een beetje de smaak van illegale praktijken in mijn mond van het woord proxy. En als dat niet het geval is wil je misschien vertellen wat je wel wilt gaan maken?
?
Onbekende gebruiker
05-01-2017 21:53
gewijzigd op 05-01-2017 22:50
Niks -
Max Hopper op 04/01/2017 17:30:59
En proxy.php:
<?php
preg_match("~.php$~", $_SERVER["REQUEST_URI"])
? include basename($_SERVER["REQUEST_URI"])
: http_response_code(404);
?>
