Hoe kan ik een wachtwoord zetten op bepaalde urls op mijn website met htacess?
Dat probeer ik met de volgende code:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
RewriteEngine on
DirectoryIndex
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,NE,R=301]
#Indexes uitzetten
Options -Indexes
#Cross site access toestaan
Header set Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
#CMS rewrite
RewriteRule ^cms/$ /cms/administrator [L]
#mysitename
DirectoryIndex index.php
SetEnvIf Request_URI ^leden/(.*).html auth=1
AuthName "Please login"
AuthType Basic
AuthUserFile "/home/mysitename/public_html/.htpasswd"
# first, allow everybody
Order Allow,Deny
Satisfy any
Allow from all
Require valid-user
# then, deny only if required
Deny from env=auth
RewriteRule ^leden/(.*).html catlisting.php?alias=$1 [QSA,L]
RewriteRule ^info/(.*).html catlisting.php?alias=$1 [QSA,L]
RewriteRule ^events/(.*).html events.php?alias=$1 [QSA,L]
RewriteRule ^projecten/(.*).html projecten.php?alias=$1 [QSA,L]
RewriteRule ^product/(.*).html product.php?alias=$1 [QSA,L]
RewriteRule ^catalogus/(.*).html catalogus.php?alias=$1 [QSA,L]
RewriteRule ^(.*).html content.php?alias=$1 [QSA,L]
ErrorDocument 404 /error/404.php
ErrorDocument 403 /error/403.php
ErrorDocument 500 /error/500.php
ErrorDocument 501 /error/501.php
ErrorDocument 503 /error/503.php
ErrorDocument 504 /error/504.php
DirectoryIndex
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,NE,R=301]
#Indexes uitzetten
Options -Indexes
#Cross site access toestaan
Header set Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
#CMS rewrite
RewriteRule ^cms/$ /cms/administrator [L]
#mysitename
DirectoryIndex index.php
SetEnvIf Request_URI ^leden/(.*).html auth=1
AuthName "Please login"
AuthType Basic
AuthUserFile "/home/mysitename/public_html/.htpasswd"
# first, allow everybody
Order Allow,Deny
Satisfy any
Allow from all
Require valid-user
# then, deny only if required
Deny from env=auth
RewriteRule ^leden/(.*).html catlisting.php?alias=$1 [QSA,L]
RewriteRule ^info/(.*).html catlisting.php?alias=$1 [QSA,L]
RewriteRule ^events/(.*).html events.php?alias=$1 [QSA,L]
RewriteRule ^projecten/(.*).html projecten.php?alias=$1 [QSA,L]
RewriteRule ^product/(.*).html product.php?alias=$1 [QSA,L]
RewriteRule ^catalogus/(.*).html catalogus.php?alias=$1 [QSA,L]
RewriteRule ^(.*).html content.php?alias=$1 [QSA,L]
ErrorDocument 404 /error/404.php
ErrorDocument 403 /error/403.php
ErrorDocument 500 /error/500.php
ErrorDocument 501 /error/501.php
ErrorDocument 503 /error/503.php
ErrorDocument 504 /error/504.php
Alleen als ik naar een pagina toe ga, bijvoorbeeld https://mysite.nl/leden/vergaderstukken.html dan zie ik geen password popup. Wat doe ik precies verkeerd?
Maar ik houd mijn vingers gekruisd dat het met mod_rewrite lastig is. Maar waarom .htaccess, en geen PHP oplossing?
Quote:
/home/mysitename/public_html/.htpasswd
En voor het gebruikersgemak kan iedereen de .htpasswd file ook downloaden, cool.
EDIT: er wordt namelijk nergens voorkomen dat je .ht* bestanden kunt opvragen, dat zou ook in een allow/deny regel moeten staan, of nog beter, zet het in eerste instantie niet in de publieke webdirectory...
Gewijzigd op 21/12/2018 15:21:37 door Thomas van den Heuvel
Thomas van den Heuvel op 21/12/2018 15:11:25:
En voor het gebruikersgemak kan iedereen de .htpasswd file ook downloaden, cool.
Quote:
/home/mysitename/public_html/.htpasswd
En voor het gebruikersgemak kan iedereen de .htpasswd file ook downloaden, cool.
Dat wordt al standaard in Apache tegengegaan hoor. Er bestaat ook configuratie op server-niveau dan enkel op user-niveau. Of ben je een Nginx gebruiker? ;-)
Persoonlijk vind ik dat dit netjes buiten de webroot hoort. En dus op een onbereikbare plek waar een bezoeker niet bij kan.
Gewijzigd op 21/12/2018 15:46:29 door - Ariën -
- Ariën - op 21/12/2018 15:43:32:
Dat wordt al standaard in Apache tegengegaan hoor. Er bestaat ook configuratie op server-niveau dan enkel op user-niveau. Of ben je een Nginx gebruiker? ;-)
Lijkt mij beter om dit expliciet, en wellicht ten overvloede, in te stellen, of nog beter:
- Ariën - op 21/12/2018 15:43:32:
Persoonlijk vind ik dat dit netjes buiten de webroot hoort. En dus op een onbereikbare plek waar een bezoeker niet bij kan.
Want dan heb je dit probleem in eerste instantie niet.
Dus een .htaccess bestand wordt gelijk behandeld als een .htpasswd.
Enkel een .htaccess bestand bepaalt de instellingen vanuit de directory waar deze in geplaatst is. Deze kan je dan niet eenvoudig of zelfs onmogelijk in een andere directory plaatsen. Maar gebruikersnamen en (ge-encrypte) wachtwoorden zijn al een verhaal apart. Die zou je altijd lekker buiten de webroot moeten plaatsen, ongeacht dat Apache het bekijken ervan blokkeert. Maar als het niet anders zou kunnen, dan voorkomt Apache in ieder geval dat je het zomaar kan downloaden. Met PHP kan je er overigens wel bij, als je het via het bestandssysteem doet.
Maar het had in mijn ogen wel netter gekund.
Gewijzigd op 21/12/2018 16:54:03 door - Ariën -
Als je dit zelf configureert heb je deze problematiek nooit en hoef je de instellingen ook niet continu na te lopen om jezelf ervan te vergewissen dat deze inderdaad nog kloppen :p.
Gewijzigd op 21/12/2018 17:38:16 door Thomas van den Heuvel
Maar we dwalen wel een beetje af, zo ;-)
- Ariën - op 21/12/2018 12:19:30:
Ik hoopte dit eigenlijk snel en dirty even op te lossen met een .htaccess password, maar helaas werkt bovenstaande code ook niet dus zal ik het toch via PHP moeten doen.
En in de documentatie wordt begonnen met AuthType, niet AuthName. Wellicht is de volgorde van de argumenten ook belangrijk.
Een nettere -en waarschijnlijk uniformere- oplossing is nog steeds authenticatie in PHP zelf. Je hebt ook een /cms/administrator gedeelte? Hoe wordt die dan dichtgetimmerd? Kun je /leden niet op precies dezelfde manier beveiligen, maar met een "lid" rol of recht? Het klinkt alsof het een en ander nog niet helemaal uitgekristalliseerd is...
Enkel door de browser af te sluiten.
Het is leuk voor een tijdelijke beveiliging van een geheel project of bestand. Maar ik zie het niet als specifiek inlogsysteem. Ten eerste vanwege het uitloggen (wat ik al zei), het kent geen rollensysteem. Maar ook omdat je bijna metadata kan opslaan in je .htpasswd bestand. Je kan dan wel met een database werken, maar dan kan je weer net zo goed het hele inlogsysteem in PHP bouwen.
Gewijzigd op 27/12/2018 10:42:00 door - Ariën -
Hier gevonden :
https://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication
Hier code :
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<script>
// https://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication
var logout_from = '../login.php/'; // dir or file to logout from
var to_url = '../'; // dir or file to goto
(function logout() {
var userAgent = navigator.userAgent.toLowerCase();
if (userAgent.indexOf("msie") != -1) {
document.execCommand("ClearAuthenticationCache", false);
}
xhr_object = null;
if(window.XMLHttpRequest)
xhr_object = new XMLHttpRequest();
else if(window.ActiveXObject)
xhr_object = new ActiveXObject("Microsoft.XMLHTTP");
else
alert ("Your browser doesn't support XMLHTTPREQUEST");
xhr_object.open ('GET', logout_from, false, 'username', 'password');
xhr_object.send ("");
xhr_object = null;
document.location = to_url; // redirect to the url
// window.close(); // or close the window without a redirect
return false;
})();
</script>
// https://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication
var logout_from = '../login.php/'; // dir or file to logout from
var to_url = '../'; // dir or file to goto
(function logout() {
var userAgent = navigator.userAgent.toLowerCase();
if (userAgent.indexOf("msie") != -1) {
document.execCommand("ClearAuthenticationCache", false);
}
xhr_object = null;
if(window.XMLHttpRequest)
xhr_object = new XMLHttpRequest();
else if(window.ActiveXObject)
xhr_object = new ActiveXObject("Microsoft.XMLHTTP");
else
alert ("Your browser doesn't support XMLHTTPREQUEST");
xhr_object.open ('GET', logout_from, false, 'username', 'password');
xhr_object.send ("");
xhr_object = null;
document.location = to_url; // redirect to the url
// window.close(); // or close the window without a redirect
return false;
})();
</script>
@thomas Dat gedeelte is van mijn joomla cms, die regelt de hele boel dus al uit zichzelf.
Gewijzigd op 27/12/2018 12:11:20 door Snelle Jaap
En als je dat niet kunt, wilt of lukt dan zou je je natuurlijk ook af kunnen vragen waarom je Joomla in eerste instantie gebruikt. Ik vond het zelf een verschrikkelijk onhandig systeem.
Het was de bedoeling een supersimpele login te maken met maar 1 user die altijd hetzelfde is. Dus het werkt prima zo. Joomla gebruik ik eigenlijk alleen de basis van, gebruikers kunnen via joomla menu items aanmaken e.d. en dan haal ik die aanpassingen zelf uit de joomla database en gebruik die data aan de voorkant met mijn eigen code. Het is dus geen joomla cms met een joomla voorkant, zo'n beetje 70% van de cms functionaliteiten heb ik eruit gehaald.
Heb je bij wijze van test of gedachtenexperiment wel eens geprobeerd om in te schatten hoeveel tijd het kost om de functionaliteit die jij van Joomla gebruikt zelf te bouwen? Toen ik met Joomla werkte kon ik daar niet echt boomstructuren in kwijt (behalve door misbruik te maken van menu's) en aangezien jij een eind op weg bent met het bouwen van eigen structuren die meer dan één niveau diep zijn zou ik mijzelf hardop de vraag stellen of Joomla je niet meer in de weg zit dan tegemoet komt.
Klopt. Voorlopig gaat het prima maar in de toekomst is het inderdaad handig zelf iets te bouwen.
Gewijzigd op 28/12/2018 12:41:53 door - Ariën -