Type in your suggestion - new feature or improvement idea

Restricted access to documents and images (member only files)

Current behavior:
If users have a direct link to a file, they will have the ability to download it (i.e. page permissions are not inherited by the files on those pages)

Desired behavior:
Restrict folders and the files in those folders by membership/administrative/group level

136 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)

    We’ll send you updates on this idea

    anonymous_206.223.175.10anonymous_206.223.175.10 shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Randall RenschRandall Rensch shared a merged idea: Secure restriction on file access, including txt and pdf (Apache .htaccess level security)  ·   · 
    Randall RenschRandall Rensch shared a merged idea: Securely restrict stored files and Member accessible files in passworded folders, inaccessible to robots.  ·   · 
    Anonymous shared a merged idea: secure documents and files  ·   · 
    Tiffany TrustyTiffany Trusty shared a merged idea: Secure Document Repository  ·   · 
    Anonymous shared a merged idea: Password protect whole directories  ·   · 
    Anonymous shared a merged idea: Password Protect Directories  ·   · 

    83 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • CVMG_webadminCVMG_webadmin commented  ·   ·  Flag as inappropriate

        This requirement, like user-accessible backup/restore, is table stakes for any business offering web services for money.
        So, a requirements spec is quite simple: look at any other site (ie Dropbox) and implement what they have. Quite simply put, give public/members and administrators appropriate access (no access, read,or read/write/create access) to each file.
        With this number of votes, why does this requirement continue to fall to the bottom of the stack?

      • Anonymous commented  ·   ·  Flag as inappropriate

        I echo all of Randall's comments and concerns. Over the past 20 years I've worked on various publishing systems: they all have a built-in security system or functionality to create one. Apache servers use a .htaccess file for access. I am not a server admin and know nothing about WA infrastructure, but if WA is using Apache servers, it seems this could be a possibility.

        Hacks, such as using Google Docs, Dropbox, etc, are not acceptable. These fragment our editing/publishing process and make it more difficult.

        Our organization has sensitive information we want to keep hidden from the public. Currently, our content is in WA and sensitive files are hosted on an Apache file server to preserve security. The additional server costs extra money. Not ideal. I hope WA comes up with a solution soon.

      • Randall RenschRandall Rensch commented  ·   ·  Flag as inappropriate

        I know nothing (well, not enough to be useful) about servers; I've always specified Apache for the shared-server sites I've run. But I'm kinda getting the impression that WA is running your own proprietary OS or something. I can't imagine file security not being built into any major server OS.

        Anyway, maybe there's a workaround for now ... is there a way we can encrypt our PDF files before or after uploading, and have your system decrypt them based on a simple password? That might not keep out the Kremlin, but would keep spiders from publishing anything useful.

        I wouldn't expect our people to start encrypting files before uploading them, expecting Members to download and decrypt them, but some browsers (or your system?) insist that PDF files be downloaded before viewing anyway (bummer!), so this might also be an option. Pretty clunky, but better than distributing our financial data and such publicly. Suggestions as to third-party software for this?

        Note however, we also store some PDF files that we WANT people to see. For example the details of attending a certain event or excursion.

      • Randall RenschRandall Rensch commented  ·   ·  Flag as inappropriate

        Currently if a person or spider knows or guesses a file's exact URL, they can read it. Even if that file can be otherwise accessed by users only by logging in and navigating to it.

        This is ABSOLUTELY CRITICAL. We can't post our meeting minutes to Members without them showing up in Google? And even if we then change the file names in order to break SERP links, the files still show up in Google's cache.

        Measures recommended by Google and WA are totally inadequate because:

        They are on the honor system (e.g. robots.txt, DoNotIndex meta tags, etc.)
        We can't predict all spiders. There are more Search Engines than Google.
        We can't even implement those, because we do not have access to our own robots.txt or page headers.
        Apparently Google no longer takes "manual" requests to be removed from display.
        Meta tags are irrelevant where PDF files are concerned.

        I don't understand why WA can't implement this (currently it's not even on their work-in-progress agenda?); it should have been integral with their product from day one? What organization does not have documents they need to circulate only to members, or store centrally, or make available to admins ... without making them public?

      • Randall RenschRandall Rensch commented  ·   ·  Flag as inappropriate

        I see references to a "design solution" in this thread, but they date back to Sept 2015, and it's not on your current Road Map. Currently you seem to be saying that truly restricted, secure page/file access is not expected in the foreseeable future. Can you explain?

        And sorry to air the following laundry in public, but this is a critical issue and has been an issue too long...

        Some aspects of WA are very nice and the concept of consolidating admin activities is sound (even if some aspect of WA itself aren't exactly "consolidated" yet), but having to repeatedly train our frequently revolving admin users in your quirks, limitations, and workarounds, ... and the cost for what we're getting ... makes it difficult to keep justifying our staying here. (It's a group decision.) One thing that makes it difficult is that we'd enjoy more data security with a $15/mo hosting account, spreadsheets and a $60 SSL cert. Please don't make our decision easy!

      • Randall RenschRandall Rensch commented  ·   ·  Flag as inappropriate

        Keep PDF files behind a strongly password-protected firewall. No one, no spider, should be able to access a confidential file unless logged in to our site as a Member. Google is NOT a member! You should also display the URL of documents etc such that it corresponds to the menu architecture. When pages are two levels down on the menu, or behind a password, why does the URL show them in root? (PS: Javascript, nofollow and robot.txt restrictions are NOT sufficient sufficient solutions to this. Don't depend on an honor system.

      • Randall RenschRandall Rensch commented  ·   ·  Flag as inappropriate

        This should be Development Priority One. That our organizations private documents cannot be secured without turning them into web pages is absolutely crippling. (Not to mention somewhat angering if there is no warning from WA during uploads. I didn't upload them, so I don't know about that.)

        There are some measures that can be taken, but they're far short of a solution. Documents can be specified (as partial names) in robots.txt, and SE's can be asked not to catalog or display them, but this relies on spiders' polite behavior, which is hardly universal. Renaming our documents and/or their URLs might break the links, but that would probably be only temporary. As WA doesn't automatically provide traffic logs (nor apparently have access to them), we don't know what spiders have visited. And support could not tell me how Google discovered our documents. (Oddly, Google has cataloged only one particular type of document, and we don't yet know why. Hopefully that will provide a clue or even a solution.)

        Repeat, if this protection is implemented by next weekend, it would still not be soon enough. Every organization should be able to exchange and post files without them becoming public.

      • Anonymous commented  ·   ·  Flag as inappropriate

        We need a way to restrict access to files, folders, and documents so that they can only be accessed and downloaded by people who are logged in current members.

      • Skip ReddySkip Reddy commented  ·   ·  Flag as inappropriate

        This feature functionality is extraordinarily important. When I asked about this feature in a support ticket, I was directed to another item.

        I reiterate that this should absolutely be considered a core feature. I also would like to know how many votes does this actually need to be implemented.

      • Anonymous commented  ·   ·  Flag as inappropriate

        As mentioned by others, file protection should be a core feature.

        The whole purpose of our organization switching to Wild Apricot was to consolidate web content, a blog, and a forum in one user-friendly system. If file protection isn't possible soon, I'll need to look at using another source or keep paid subscriptions for two web hosting companies.

        Please move file protection to the top of the list. How long will it take?

      • Colin SheadColin Shead commented  ·   ·  Flag as inappropriate

        Hi

        We have been waiting for this rather basic 'core feature' for a very long time. Because of this, other poorly implemented features and rising costs, my organisation has decided to leave Wild Apricot, and have developed an alternative an 100% secure solution of our own to which we are migrating.

        All the best

        Colin

      • Russell NobleRussell Noble commented  ·   ·  Flag as inappropriate

        So how many votes does this actually need to be implemented.
        Member only documents is a pretty core feature.

      • Scott HendisonScott Hendison commented  ·   ·  Flag as inappropriate

        Please implement the suggested bugfix already... A basic function of a membership site should be to protect "members only" content.

      • Tiffany TrustyTiffany Trusty commented  ·   ·  Flag as inappropriate

        We really need a secure document repository solution! You got me out of spreadsheet hell, now get me out of SharePoint / DropBox / GoogleDocs purgatory!

      • dbreslaudbreslau commented  ·   ·  Flag as inappropriate

        As an administrator of a WA site that requires this feature, I believe it's necessary to investigate other hosting options if this feature isn't implemented fairly soon. As a developer, I have a very hard time understanding why it wasn't already implemented.

        P.S: Please consider creating a version of this support website that is managed by the Wild Apricot software. Keep the WA version internal if you must. Regardless, I think the experience would give you some valuable insights into your customer's experiences and requirements. (And if you can make it robust enough to serve as the public website, it would probably help you a lot in selling your product.)

      ← Previous 1 3 4 5

      Feedback and Knowledge Base

      Wild Apricot Inc. 144 Front Street West Suite 725, Toronto, Ontario, Canada M5J 2L7