Require all denied has no effect. Require all allowed, worksApache2 & .htaccess : Apache ignoring...

Do black holes violate the conservation of mass?

Can I negotiate a patent idea for a raise, under French law?

Why does this boat have a landing pad? (SpaceX's GO Searcher) Any plans for propulsive capsule landings?

Are these two graphs isomorphic? Why/Why not?

What is this tube in a jet engine's air intake?

What will happen if my luggage gets delayed?

I can't die. Who am I?

Movie: boy escapes the real world and goes to a fantasy world with big furry trolls

School performs periodic password audits. Is my password compromised?

How do I raise a figure (placed with wrapfig) to be flush with the top of a paragraph?

Has a sovereign Communist government ever run, and conceded loss, on a fair election?

Rationale to prefer local variables over instance variables?

Why restrict private health insurance?

Trocar background-image com delay via jQuery

What do you call someone who likes to pick fights?

Finding the minimum value of a function without using Calculus

Cycles on the torus

-1 to the power of a irrational number

How do we create new idioms and use them in a novel?

How can I portion out frozen cookie dough?

Use Mercury as quenching liquid for swords?

What is the purpose of a disclaimer like "this is not legal advice"?

Boss Telling direct supervisor I snitched

Is it possible to clone a polymorphic object without manually adding overridden clone method into each derived class in C++?



Require all denied has no effect. Require all allowed, works


Apache2 & .htaccess : Apache ignoring AccessFile.htaccess has no effectApache2 “Require all granted” doesn't workWhat does Apache's “Require all granted” really do?How to deny everyone access except certain hosts and IPs with Apache 2.4?Specify which directores to look for .htaccess file.htaccess file is not working on Apache 2.4.12 and Windows Server 2008 R2.htaccess deny/allow rules denying folder, but not direct to filesMove htaccess rules to apache configuration files.htaccess: Allow all connections from local network, but require login for external













4















I have a website structure setup as follows, which I am trying to organize access levels for each but without specifying <Directory> as that requires the structure to be fixed (aka, if i copy this to a different site, into a subfolder, it would require editing of all .htaccess to the new location).





  • /app/ - allow all, deny config/etc


  • /app/templates/ - deny all


  • /app/templates/mytheme/ - allow all for images, javascript, css, fonts only


  • /app/lib/ - deny all


I have tried implementing Apache2.4's new(ish) directive scheme:



/etc/apache2/conf-enabled/security.conf



... more stuff above ...

<Directory />
AllowOverride All
Require all denied
</Directory>

... more stuff below ...


And adding Require all allowed to .htaccess in the root of the application, while adding Require all denied to .htaccess in the folders I wish to deny access to.



The problem is Require all denied seems to do absolutely nothing. I have seen reference to using the mod_auth_compat or whichever library, but it appears to only be required for older versions of apache (v2.3).



I am using Apache 2.4 on Debian 8.



Previously, I would supply :



Order Allow, Deny
Deny from all


And then drop the following in folders which require access :



Allow from all


.. and where I need to allow only specific file type access,



<FilesMatch ".(jpg|jpeg|gif|png|bmp|svg|css|less|sass|scss|js|ttf|woff|woff2|eot)$">
Allow from all
</FilesMatch>


According to apache's documentation, unexpected results may arise from mixing old and new declarations, and as such, I am only using new declarations. There are no stray .htaccess files or *.conf files loaded using the old declaration format for permissions - so this should work ?



Given the folder structure I laid out, and what is loaded in '/etc/apache2/conf-enabled/security.conf' (as that is where the "root" declaration is for AllowOverride [it doesn't seem to function when specifying AllowOverride All inside the same format of declaration in the websites conf ( 000-default.conf )], could someone give some guidance or preferably a working solution to this problem.










share|improve this question














bumped to the homepage by Community 7 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.











  • 2





    NOTE: Require all allowed (copied from your question) is not proper 2.4. Should be Require all granted

    – Colt
    Apr 18 '16 at 3:16











  • Although Require all allowed would result in a 500 error, so I guess that must be a typo? (Or the code isn't being processed which could also explain why it "seems to do absolutely nothing?)

    – MrWhite
    Apr 18 '16 at 15:56











  • sorry, was exhausted when i wrote this. it was require all granted. since it's been a few days, i will test require all granted to see if i was also sleepy when playing with .htaccess. UPDATE: Yup, I was sleepy. Require all granted works perfectly. TY so much :)

    – Kraang Prime
    Apr 19 '16 at 15:58


















4















I have a website structure setup as follows, which I am trying to organize access levels for each but without specifying <Directory> as that requires the structure to be fixed (aka, if i copy this to a different site, into a subfolder, it would require editing of all .htaccess to the new location).





  • /app/ - allow all, deny config/etc


  • /app/templates/ - deny all


  • /app/templates/mytheme/ - allow all for images, javascript, css, fonts only


  • /app/lib/ - deny all


I have tried implementing Apache2.4's new(ish) directive scheme:



/etc/apache2/conf-enabled/security.conf



... more stuff above ...

<Directory />
AllowOverride All
Require all denied
</Directory>

... more stuff below ...


And adding Require all allowed to .htaccess in the root of the application, while adding Require all denied to .htaccess in the folders I wish to deny access to.



The problem is Require all denied seems to do absolutely nothing. I have seen reference to using the mod_auth_compat or whichever library, but it appears to only be required for older versions of apache (v2.3).



I am using Apache 2.4 on Debian 8.



Previously, I would supply :



Order Allow, Deny
Deny from all


And then drop the following in folders which require access :



Allow from all


.. and where I need to allow only specific file type access,



<FilesMatch ".(jpg|jpeg|gif|png|bmp|svg|css|less|sass|scss|js|ttf|woff|woff2|eot)$">
Allow from all
</FilesMatch>


According to apache's documentation, unexpected results may arise from mixing old and new declarations, and as such, I am only using new declarations. There are no stray .htaccess files or *.conf files loaded using the old declaration format for permissions - so this should work ?



Given the folder structure I laid out, and what is loaded in '/etc/apache2/conf-enabled/security.conf' (as that is where the "root" declaration is for AllowOverride [it doesn't seem to function when specifying AllowOverride All inside the same format of declaration in the websites conf ( 000-default.conf )], could someone give some guidance or preferably a working solution to this problem.










share|improve this question














bumped to the homepage by Community 7 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.











  • 2





    NOTE: Require all allowed (copied from your question) is not proper 2.4. Should be Require all granted

    – Colt
    Apr 18 '16 at 3:16











  • Although Require all allowed would result in a 500 error, so I guess that must be a typo? (Or the code isn't being processed which could also explain why it "seems to do absolutely nothing?)

    – MrWhite
    Apr 18 '16 at 15:56











  • sorry, was exhausted when i wrote this. it was require all granted. since it's been a few days, i will test require all granted to see if i was also sleepy when playing with .htaccess. UPDATE: Yup, I was sleepy. Require all granted works perfectly. TY so much :)

    – Kraang Prime
    Apr 19 '16 at 15:58
















4












4








4


0






I have a website structure setup as follows, which I am trying to organize access levels for each but without specifying <Directory> as that requires the structure to be fixed (aka, if i copy this to a different site, into a subfolder, it would require editing of all .htaccess to the new location).





  • /app/ - allow all, deny config/etc


  • /app/templates/ - deny all


  • /app/templates/mytheme/ - allow all for images, javascript, css, fonts only


  • /app/lib/ - deny all


I have tried implementing Apache2.4's new(ish) directive scheme:



/etc/apache2/conf-enabled/security.conf



... more stuff above ...

<Directory />
AllowOverride All
Require all denied
</Directory>

... more stuff below ...


And adding Require all allowed to .htaccess in the root of the application, while adding Require all denied to .htaccess in the folders I wish to deny access to.



The problem is Require all denied seems to do absolutely nothing. I have seen reference to using the mod_auth_compat or whichever library, but it appears to only be required for older versions of apache (v2.3).



I am using Apache 2.4 on Debian 8.



Previously, I would supply :



Order Allow, Deny
Deny from all


And then drop the following in folders which require access :



Allow from all


.. and where I need to allow only specific file type access,



<FilesMatch ".(jpg|jpeg|gif|png|bmp|svg|css|less|sass|scss|js|ttf|woff|woff2|eot)$">
Allow from all
</FilesMatch>


According to apache's documentation, unexpected results may arise from mixing old and new declarations, and as such, I am only using new declarations. There are no stray .htaccess files or *.conf files loaded using the old declaration format for permissions - so this should work ?



Given the folder structure I laid out, and what is loaded in '/etc/apache2/conf-enabled/security.conf' (as that is where the "root" declaration is for AllowOverride [it doesn't seem to function when specifying AllowOverride All inside the same format of declaration in the websites conf ( 000-default.conf )], could someone give some guidance or preferably a working solution to this problem.










share|improve this question














I have a website structure setup as follows, which I am trying to organize access levels for each but without specifying <Directory> as that requires the structure to be fixed (aka, if i copy this to a different site, into a subfolder, it would require editing of all .htaccess to the new location).





  • /app/ - allow all, deny config/etc


  • /app/templates/ - deny all


  • /app/templates/mytheme/ - allow all for images, javascript, css, fonts only


  • /app/lib/ - deny all


I have tried implementing Apache2.4's new(ish) directive scheme:



/etc/apache2/conf-enabled/security.conf



... more stuff above ...

<Directory />
AllowOverride All
Require all denied
</Directory>

... more stuff below ...


And adding Require all allowed to .htaccess in the root of the application, while adding Require all denied to .htaccess in the folders I wish to deny access to.



The problem is Require all denied seems to do absolutely nothing. I have seen reference to using the mod_auth_compat or whichever library, but it appears to only be required for older versions of apache (v2.3).



I am using Apache 2.4 on Debian 8.



Previously, I would supply :



Order Allow, Deny
Deny from all


And then drop the following in folders which require access :



Allow from all


.. and where I need to allow only specific file type access,



<FilesMatch ".(jpg|jpeg|gif|png|bmp|svg|css|less|sass|scss|js|ttf|woff|woff2|eot)$">
Allow from all
</FilesMatch>


According to apache's documentation, unexpected results may arise from mixing old and new declarations, and as such, I am only using new declarations. There are no stray .htaccess files or *.conf files loaded using the old declaration format for permissions - so this should work ?



Given the folder structure I laid out, and what is loaded in '/etc/apache2/conf-enabled/security.conf' (as that is where the "root" declaration is for AllowOverride [it doesn't seem to function when specifying AllowOverride All inside the same format of declaration in the websites conf ( 000-default.conf )], could someone give some guidance or preferably a working solution to this problem.







.htaccess apache-2.4






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Apr 15 '16 at 18:36









Kraang PrimeKraang Prime

14319




14319





bumped to the homepage by Community 7 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







bumped to the homepage by Community 7 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.










  • 2





    NOTE: Require all allowed (copied from your question) is not proper 2.4. Should be Require all granted

    – Colt
    Apr 18 '16 at 3:16











  • Although Require all allowed would result in a 500 error, so I guess that must be a typo? (Or the code isn't being processed which could also explain why it "seems to do absolutely nothing?)

    – MrWhite
    Apr 18 '16 at 15:56











  • sorry, was exhausted when i wrote this. it was require all granted. since it's been a few days, i will test require all granted to see if i was also sleepy when playing with .htaccess. UPDATE: Yup, I was sleepy. Require all granted works perfectly. TY so much :)

    – Kraang Prime
    Apr 19 '16 at 15:58
















  • 2





    NOTE: Require all allowed (copied from your question) is not proper 2.4. Should be Require all granted

    – Colt
    Apr 18 '16 at 3:16











  • Although Require all allowed would result in a 500 error, so I guess that must be a typo? (Or the code isn't being processed which could also explain why it "seems to do absolutely nothing?)

    – MrWhite
    Apr 18 '16 at 15:56











  • sorry, was exhausted when i wrote this. it was require all granted. since it's been a few days, i will test require all granted to see if i was also sleepy when playing with .htaccess. UPDATE: Yup, I was sleepy. Require all granted works perfectly. TY so much :)

    – Kraang Prime
    Apr 19 '16 at 15:58










2




2





NOTE: Require all allowed (copied from your question) is not proper 2.4. Should be Require all granted

– Colt
Apr 18 '16 at 3:16





NOTE: Require all allowed (copied from your question) is not proper 2.4. Should be Require all granted

– Colt
Apr 18 '16 at 3:16













Although Require all allowed would result in a 500 error, so I guess that must be a typo? (Or the code isn't being processed which could also explain why it "seems to do absolutely nothing?)

– MrWhite
Apr 18 '16 at 15:56





Although Require all allowed would result in a 500 error, so I guess that must be a typo? (Or the code isn't being processed which could also explain why it "seems to do absolutely nothing?)

– MrWhite
Apr 18 '16 at 15:56













sorry, was exhausted when i wrote this. it was require all granted. since it's been a few days, i will test require all granted to see if i was also sleepy when playing with .htaccess. UPDATE: Yup, I was sleepy. Require all granted works perfectly. TY so much :)

– Kraang Prime
Apr 19 '16 at 15:58







sorry, was exhausted when i wrote this. it was require all granted. since it's been a few days, i will test require all granted to see if i was also sleepy when playing with .htaccess. UPDATE: Yup, I was sleepy. Require all granted works perfectly. TY so much :)

– Kraang Prime
Apr 19 '16 at 15:58












1 Answer
1






active

oldest

votes


















0














See the upgrade guide with examples on the Require Directive: https://httpd.apache.org/docs/trunk/en/upgrading.html





  • Deny from all is now Require all denied


  • Allow from all is now Require all granted


Plot twist: Apache 2.4 doesn't grant access to any directory by default and the order of evaluation has changed.



It was commonplace to block access to the filesystem in apache 2.2, with a Directory / + Require all denied as you wrote. It should be removed now. It will backfire if it ever supersedes permissions in subdirectories.



See the documentation on merging authentication restrictions. It gets insanely complicated in practice. https://httpd.apache.org/docs/trunk/en/mod/mod_authz_core.html#authmerging



The Require all granted in /app is evaluated before the Require all denied in the /app/lib subdirectory. It looks like apache grants access upon meeting the first allowing rule so it's allowed. The whole tree got opened by the directive on the parent and there is not a lot you can do against that.



My advise is to not mix public and private content. It's completely unmanageable in practice. If it's served, it's meant to be served.






share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "2"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f770709%2frequire-all-denied-has-no-effect-require-all-allowed-works%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    See the upgrade guide with examples on the Require Directive: https://httpd.apache.org/docs/trunk/en/upgrading.html





    • Deny from all is now Require all denied


    • Allow from all is now Require all granted


    Plot twist: Apache 2.4 doesn't grant access to any directory by default and the order of evaluation has changed.



    It was commonplace to block access to the filesystem in apache 2.2, with a Directory / + Require all denied as you wrote. It should be removed now. It will backfire if it ever supersedes permissions in subdirectories.



    See the documentation on merging authentication restrictions. It gets insanely complicated in practice. https://httpd.apache.org/docs/trunk/en/mod/mod_authz_core.html#authmerging



    The Require all granted in /app is evaluated before the Require all denied in the /app/lib subdirectory. It looks like apache grants access upon meeting the first allowing rule so it's allowed. The whole tree got opened by the directive on the parent and there is not a lot you can do against that.



    My advise is to not mix public and private content. It's completely unmanageable in practice. If it's served, it's meant to be served.






    share|improve this answer




























      0














      See the upgrade guide with examples on the Require Directive: https://httpd.apache.org/docs/trunk/en/upgrading.html





      • Deny from all is now Require all denied


      • Allow from all is now Require all granted


      Plot twist: Apache 2.4 doesn't grant access to any directory by default and the order of evaluation has changed.



      It was commonplace to block access to the filesystem in apache 2.2, with a Directory / + Require all denied as you wrote. It should be removed now. It will backfire if it ever supersedes permissions in subdirectories.



      See the documentation on merging authentication restrictions. It gets insanely complicated in practice. https://httpd.apache.org/docs/trunk/en/mod/mod_authz_core.html#authmerging



      The Require all granted in /app is evaluated before the Require all denied in the /app/lib subdirectory. It looks like apache grants access upon meeting the first allowing rule so it's allowed. The whole tree got opened by the directive on the parent and there is not a lot you can do against that.



      My advise is to not mix public and private content. It's completely unmanageable in practice. If it's served, it's meant to be served.






      share|improve this answer


























        0












        0








        0







        See the upgrade guide with examples on the Require Directive: https://httpd.apache.org/docs/trunk/en/upgrading.html





        • Deny from all is now Require all denied


        • Allow from all is now Require all granted


        Plot twist: Apache 2.4 doesn't grant access to any directory by default and the order of evaluation has changed.



        It was commonplace to block access to the filesystem in apache 2.2, with a Directory / + Require all denied as you wrote. It should be removed now. It will backfire if it ever supersedes permissions in subdirectories.



        See the documentation on merging authentication restrictions. It gets insanely complicated in practice. https://httpd.apache.org/docs/trunk/en/mod/mod_authz_core.html#authmerging



        The Require all granted in /app is evaluated before the Require all denied in the /app/lib subdirectory. It looks like apache grants access upon meeting the first allowing rule so it's allowed. The whole tree got opened by the directive on the parent and there is not a lot you can do against that.



        My advise is to not mix public and private content. It's completely unmanageable in practice. If it's served, it's meant to be served.






        share|improve this answer













        See the upgrade guide with examples on the Require Directive: https://httpd.apache.org/docs/trunk/en/upgrading.html





        • Deny from all is now Require all denied


        • Allow from all is now Require all granted


        Plot twist: Apache 2.4 doesn't grant access to any directory by default and the order of evaluation has changed.



        It was commonplace to block access to the filesystem in apache 2.2, with a Directory / + Require all denied as you wrote. It should be removed now. It will backfire if it ever supersedes permissions in subdirectories.



        See the documentation on merging authentication restrictions. It gets insanely complicated in practice. https://httpd.apache.org/docs/trunk/en/mod/mod_authz_core.html#authmerging



        The Require all granted in /app is evaluated before the Require all denied in the /app/lib subdirectory. It looks like apache grants access upon meeting the first allowing rule so it's allowed. The whole tree got opened by the directive on the parent and there is not a lot you can do against that.



        My advise is to not mix public and private content. It's completely unmanageable in practice. If it's served, it's meant to be served.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Feb 3 at 23:54









        user5994461user5994461

        1,4021020




        1,4021020






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Server Fault!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f770709%2frequire-all-denied-has-no-effect-require-all-allowed-works%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            As a Security Precaution, the user account has been locked The Next CEO of Stack OverflowMS...

            Список ссавців Італії Природоохоронні статуси | Список |...

            Українські прізвища Зміст Історичні відомості |...