X3 Beta V0.11
[Password Protected Pages]
Apart from fixing a few minor bugs [1,2,3,4], this update is all about password-protected pages in X3. I wish new features like this did not take so long, but when we add something, we want to do it properly.
Upgrade Instructions
You need to update ALL files from the latest X3 release, except your /content/ folder as usual. Also, remember to make backup of your /panel/config.php so you can keep it (panel/config.php has not changed in this release, so you can ignore it). There is a new file in root called "protect.php", which needs to be writeable from the panel. Also, we have upgraded CSS and JS files (on the CDN) to 0.11.
PS! The protect section contains some demo links and users by default, which may be removed once you understand the concept.
Usage
There is a new "Protect" section in the admin panel, which allows you to password-protect links. I will give some examples with screenshots instead of writing too much.
To protect a specific link, just select it in the link-dropdown list, and add a username and password:
Recursive Protection
Link protection is recursive, which means the login for a specific link will inherit upon child pages. The example above will automatically protect the specified page galleries/ as well as any child pages like galleries/food/ and galleries/landscape/. If you are protecting child-pages of already-protected parent-pages, the child-page login will outrank the parent-page login.
You could also ignore username and only set the password, but generally this is not recommended:
Users
Instead of adding a simple username and password, you can add "users" who can access the page:
Users are added from the "users" tab ...
Benefits of "Users"
The benefit of "users", is that you can assign a single login to a person, which may allow them access to multiple protected pages without re-entering login credentials. Also, it is sometimes easier to store username and password in a users section for persistent usage. If you have basic protection requirements, there is however nothing wrong with ignoring users, and just adding a username and password for a specific link.
You can have both "users" and "username + password", although I don't see any logical reason why you would want that:
You can also group multiple links in the same entry, which could be beneficial in some cases:
Just keep in mind, since protected links are recursive, the following would NOT be logical:
In the above, you are basically protecting pages /galleries/food/ and /galleries/style/ which are already protected by the same login with /galleries/.
Global Protection
Use the special *Global link to protect your entire X3 website. Basically this is like protecting the / root page, and since link-protection is recursive, it will protect ALL pages and basically your entire website.
In the event where you have multiple entries that may recursively affect the same links, the child-most link will count first.
In the example above, when accessing link /galleries/food/, only "demouser1" will have access since it is the child-link branch. This allows you to for example create a protected-area of galleries available to many users, while child pages may only be available to some users.
Super Users
There is a special user type we call "super users", which are basically allowed access to ALL password-protected pages without even being assigned. A super-user should normally be reserved for gallery-owners who just want to remember a single login that works on all password-protected pages. Create a super-user by simply appending an asterisk* behind the username.
* Since super-users are allowed access to ALL password-protected pages, they do not show up in the list of available users to assign from the links tab.
* The asterisk* character is part of the username, and needs to be included when logging in.
NOTES
Sessions
X3 login uses WWW-Authenticate, which basically creates "sessions" in the browser that remembers the current authentication. This helps so the visitor doesn't need to re-authenticate, and it also allows a "user" to access all pages they are assigned to without having to enter login details more than once. This is a good thing of course, but since there is no "logout" for these sessions, it can make testing difficult from your browser since you may be logged in to a session already ...
Testing ...
Therefore, if you are testing your protected pages, you may need to use "New Incognito Window" (Google Chrome), or "New Private Window" (Safari, Firefox) for each test. These special windows do not inherit your browser sessions, so you can test properly. Just remember to to open/close the window for each test, because even private windows have temporary sessions until they are closed.
Open_Basedir
I am not quite sure yet, but I am guessing there will be problems with passwords feature for those who are forced on servers with open_basedir restriction. Why? Because these open_basedir settings seem to prevent PHP from being able to write to PHP files, which is necessary when editing logins from the panel.
How secure is it?
Unless your FTP or panel is compromised, it is secure. Nobody can access an X3 page unless they know the login. One important thing to keep in mind though, is that Auth password-protection is part of the X3 application, and basically protects pages that belong to X3. It cannot protect any custom folders/pages/files on your server that do not belong to X3. This does in fact include images in your X3 content folder, although realistically speaking, they are already protected by X3 pages.
No encryption on stored passwords?
For practical reasons, we have decided to not store passwords encrypted. Why? First of all, because it provides no benefit in terms of security ... If someone manages to locate the passwords, it is because they broke into your server FTP or panel somehow, in which case they can easily set their own passwords anyway. Furthermore, the passwords stored are for viewing pages and don't provide any capabilities to change anything anyway. Finally, it makes sense to have the panel "protect" section available to look up on usernames and passwords ... It would be very tedious with a "reset password" system which provides no additional security.
Why are logins not set directly from pages in the panel page-manager?
For technical reasons, link logins are stored separately from pages, in a single file protect.php. There are many reasons for this, but the main reason is that an X3-page includes a create-and-cache process, which we want to avoid just for authenticating. Instead, logins are stored in a single file, and X3 acts as a "router", intercepting URL's with login before the page gets processed. Also, even if we did store logins with the page data, we would still need to store "users" in a separate location. In the future, it may be possible to edit logins for a page directly from the panel page manager.
A few more things ...
# Protected pages are for obvious reasons NOT preloaded, if you are using the X3 preload feature.
# You cannot have multiple identical link entries because the link is the key used to check associated users/username/password.
# You cannot have multiple identical usernames, because the username is the key that identifies the login attempt.