Search the Community
Showing results for tags 'password-protection'.
Hello everyone. I have a "newby"'s question regarding password protecting the front end of on one of my website. The web site in question is for the members of a small scale non profit organisation. It should not be easily accessed by non members but they don't want to force their members to create a personal user account. From their point of view a simple common password should be enough. Here is my question : Can I use a newly created user and in the login form only ask for the password (I will feed the username in the code). In this case many users will potentially log with the same user at the same time. Is this approach correct, are there any drawbacks (performance ?)... or is it realy a bad idea 🙂 Otherwise I can just implement a simple password protection function without using the user system (didn't find a module addressing that need). Thanks for your help
Hi, I'm hammering out the details of a project for a consortium of counseling organizations. They need a new site for sharing private case information and related knowledge, and they have a very small budget. My question is: Is this site a good fit for ProcessWire, or should I build this using a Wiki engine like MediaWiki or DokuWiki? Or something else? Here are some of the requirements: The site is access-protected so that only authorized accounts can see any site content at all—approximately 20 active users at a given time. Content types: The majority of content would be informational articles in formatted text, but the site will give them easy control over a dynamic, hierarchical category list under which content can be easily organized. They will also need to upload and link to documents, including PDFs and Word docs. All content, including uploaded files, would be available only to logged-in user accounts. Multiple editors: Users can update text, create new pages, add categories, and upload and link documents. All users would have editor privileges, but they anticipate fewer than 10 will actually do it. Recent updates: They want a section that lists recent substantial updates to the site. Based on the discussion, they prefer not to include minor article edits (like a phrase being changed to bold, for example), but only edits that change the content in substance—sounds like this could easily be accomplished with an internal blog. Alerts: Any member can post a comment on an article to note current questions or issues about the content. The purpose is to resolve the questions or issues and improve the article content, not to maintain a persistent discussion about article content. Full-text search Quick navigation: A concise list of links to highest-traffic content will be available on every page. This navigation menu should be easy to add, remove, sort, or edit links by the editors. I have two further requirements, for my own sake: Simplicity of user-facing interface: I don't want the publishing software to present the editors with superfluous configuration and options they might use to break the site, or require extensive documentation for. Stablility, security, and ease of maintenance: I don't want to introduce security vulnerabilities or create long-term maintenance difficulties simply by customizing the front-end page designs. It occurs to me that Wiki software has most of the above features built-in. But I have a few misgivings about using a Wiki: Wikis include a lot of built-in functionality that I imagine would make it incredibly complex to create a skin. I know that ProcessWire would allow me to write my own markup, and keep the page designs as simple as possible. I'm also afraid that I might introduce security vulnerabilities or maintainability problems if I create my own skin for a Wiki. I know that ProcessWire enables you to include back-end functionality in front-end templates, but you don't have to do that. I'm confident that I would have to do some obvious and deliberately reckless design in order to create any security problems with ProcessWire. On the other hand, I don't want to spend weeks building out functionality that a Wiki, or other easily-available software, offers with basic installation. Any guidance, warnings, advice, or further thoughts would be greatly appreciated. Cheers! John