• strangest ACL issue

    By D Ritchie 2 decades ago

    I've not encountered this before, so maybe not a DominoWiki issue.



    I want a private wiki - if I set the ACL entry -Default- to "No Access", then no one can access the .nsf via http - not even those explicitly listed as Persons/ Manager with webuser role enabled. What we get is "[USERNAME] you are not authorized to access [DBNAME]".



    So when I give -Default- just a simple "Depositor" or "Reader" access in the ACL, with no other roles or privileges enabled, all suddenly works well in http.



    Very strange. Using Notes Client, all access is as it should be.



    All the other databases on the server are allowing correct http access, no need to "slightly" enable -Default-



    Any thoughts anyone?



    Thx,

    Duke

    • Anonymous

      By Benedict R Poole 2 decades ago

      -Default- is one thing, but what level of access have you given Anonymous? In order to make Domino

      authenticate your users, Anonymous needs to be set to "No Access".



      DominoWiki is a Domino database like any other, so the ACL is standard.

      • By D Ritchie 2 decades ago

        Sorry, should have clarified. Anonymous, like default, is also set to no access w/ no roles or priviledges. When the ACL is set in this way, I get the aforementioned "weirdness". However, when I give -Default- even the slightest bit of access (say, depositor or reader, with no roles & priviledges), then I'm able to access via http using my authenticated credentials.



        Like you stated, this very well may not be a DominoWiki issue since it's not doing anything unusual with authentication. But the darnedest thing is that this only happens with this one app, and only with http access! Every other app behaves "normally" as one would expect. Any more clues?



        Thanks,

        Duke

        • By Steven Searson 2 decades ago

          Hi Duke,



          This sounds like standard Domino security.



          The fact that you have Anonymous set to No Access, is forcing you to logon. If there are any groups or users in the ACL that your authenticated user matches to, you will be allowed access. If there are no groups or names that match, the Default access will be tested. If this is set to No Access, you will not be able to access the db, and will get the not authorised message.



          If the default access is set to reader or above, you will be able to gain access.



          If you are still getting weird behaviour, make sure the Read Public Access documents check box is cleared for both Anonymous and Default entries.



          Hope this helps,



          Steve

          • Let's try this again, hopefully this is more articulate

            By Duke Ritchie 2 decades ago

            Hi Steve,



            Thanks for replying. I don't think you fully understood my issue, or more likely, I haven't articulated it well enough ;-)



            I'll try again. Also, let's leave out discussion of groups in the ACL. Let's just say for the sake of simplicity that each person has an explicit ACL entry (gasp!)



            =========

            Scenario #1

            =========

            User Ray Oz is in the ACL as:

            • Person
            • Editor
            • Create documents, read public docs, write public docs, replicate or copy docs are all checked
            • Role WebUser enabled



              Unspecified -Default- and Anonymous are in the ACL as:
            • Unspecified type
            • No Access
            • no privileges or roles of any type enabled



              There are no deny groups here, so of course Oz should be able to log in and access the app via http, right? But no, we get: "Ray Oz, you are not authorized to access -dbname-.nsf". This of course means that he has authenticated correctly, but is being denied access to this specific db.



              This is clearly not working as it should… there is no logic or rhyme or reason to this (I'm not saying it's the wiki's problem - there may be a general server issue, but maybe I can get help here anyway).



              =========

              Scenario #2

              =========

              All the same as above, except: I change -Default- access to Depositor. Again, all other privileges and roles are disabled.



              Suddenly, I'm allowed to access the database with Ray Oz's credentials, the VERY SAME ones that the server/db was not allowing to access the wiki just 30 seconds ago.



              Strange, huh? Ok, now here's…



              =========

              Scenario #2a

              =========

              I change -Default- access to Reader, again disabling all privileges & roles (except for Read public docs, which can't be disabled for Readers).



              Again, I can use Ray's credentials to log in, and yes, he can still access the db!



              Now…



              =========

              Scenario #3

              =========

              revert back to all the same settings as scenario #1, which in this case means setting -Default- to No Access with no privileges or roles.



              Restart browser again, clear cookies & cache, and try to log in as Ray Oz again, and no dice: "Ray Oz, you are not authorized to access -dbname-.nsf".



              I have to say I have never seen something this odd. I'll try to reproduce this with a new, dummy db and see if there's an issue. In the meantime, anyone else have any thoughts?



              Thanks to all who responded so far.



              -Duke
            • Corrupt ACL?

              By Steven Searson 2 decades ago

              Hi Duke,



              Apologies for the confusion with the previous post, probably the result of skim reading after a heavy weekend ;-).



              I've tried reproducing the issues you mention on our Wiki ACL and can access it fine using Default and Anonymous set to no access - I am challenged for my username and password, and once entered, I'm shown the Wiki and can edit documents no problem.



              The only thing I can think is that somehow your ACL is corrupted. It may be worth setting up a dummy db with the same ACL and then copying this to your Wiki DB using the Admin client to copy and paste over the current ACL.



              If I find anything else, I'll let you know.



              Steve

              • Here's what I've done so far

                By Duke Ritchie 2 decades ago

                Thanks for sticking w/ me on this Steve.



                I've created a dummy db, with virtually no design elements except for a page with the static text "hi there".


                1. Copied the ACL from the problematic wiki to dummy.nsf
                2. Set dummy.nsf to launch the page when access from web browser
                3. access wiki with Ray Oz credentials (just to be sure problem is still there)… same result - not allowed to access the db
                4. access dummy.nsf (remember, exact same ACL as wiki) … success!



                  This leads me to conclude that there is indeed a problem with the wiki db. Maybe a corrupted ACL? I suppose I will just archive this one and create a new one and see if I get the same problem.



                  Stay tuned…
              • Still have ACL issue

                By Duke Ritchie 2 decades ago

                Well, I'm sad to report that removing the original problematic wiki, and replacing with a new one still results in the same problem, and I just can't figure it out.

              • Smart guy

                By Duke Ritchie 2 decades ago

                So smart, I'll crown myself the Prince of RTFM. Captain ID10T, if you will. Basic ACL stuff I've done a million times over 10 years…



                So thanks for all the feedback from you guys - the problem was obvious and certainly not an issue with the wiki template.



                The solution in a nutshell:

                Basically, we have a process that dictates all code propagated to a server must be signed. So the template gets signed by a trusted ID, but I FORGOT TO GIVE THAT ID ACCESS TO THE DB!!!



                The reason the dummy.nsf "passed the test" in my previous posting is because that was just a shell database, with no lookups or any execution logic whatsoever, so although the trusted ID was not on that ACL either, it didn't matter.



                Thanks again for your help guys. Now I'm off to wiki land.

    • Is "Read public" checked for -default-?

      By Richard H Schwartz 2 decades ago

      Strange things can happen if -default- has no access with read public. You are allowed into the database by the read public permission, but you lack access to actually read data that is necessary to construct the initial page, so you get kicked out.

      • no

        By Duke Ritchie 2 decades ago

        Hi Richard,



        No, -default- and anonymous are both set to no access with no roles or privileges.



        Thanks,

        Duke