Planning v0.5 of the WordPress Password Plugin

I’ve started working on the next version of the WordPress Password Plugin (v0.5). This post is to explain what I’m planning and why, as well as to seek suggestions/feedback. This list is compiled from your suggestions and my own observations. It’s subject to change. It’s subject to not being possible to code. It’s subject to your opinions, too.

  1. Convert the in/ex-clusion list to separate “rules”
    v0.4 converts the in/ex-clude strings to Regular Expressions. Here’s why:
    Say your site is password protected, except urls containing “*not-secure”. A clever user might add “&this-is-not-secure” to the end of your urls. The system might let them in without a password then – it depends a bit on the order you put the strings in.
    I convert those strings to RE’s internally and attach them to the beginning of the whole url, to try protecting against that url hack — but it’s tricky and a badly written pattern can’t always be helped.
    The next version I release will do away with the texbox of patterns and converting them to RE’s in favor of a more straight forward, less hackable method:

    1. You define “the general rule”: Whether the whole site is protected or not, by default.
    2. You define as many separate “exceptions to the rule” as you want – specifying the text, what “field” it must (or must not) be found (e.g. id/slug/url-path/querystring) and then whether that means the post does or does not require a password.
    3. Order still matters, and you’ll be able to move rules up/down in the list as needed. As well as copy/delete/etc., but that doesn’t completely deal with all the situations I’ve thought of… more in a moment…
  2. Resolve https:// link problems
    The most common problem people have encounted so far is that version 0.4 does a bad job on https:// urls. That’s related to the RE gymnastics I’m doing internally and should go away entirely in 0.5
  3. Protect posts in lists
    I am ashamed to say I never even thought of this until after v0.4 was out. It’s just a perspective I didn’t consider until I started thinking of how to improve the plugin.
    v0.4 works by examining the urls requested from your site. It compares each url to the list of text patterns you’ve entered. If there’s a match, the plugin acts according to your settings.
    Suppose you password protect a recent post, and list the x most recent posts on your homepage, in full text. If the plugin doesn’t recognize the homepage as one to protect, it also does nothing to protect the text of your post from showing there (feeds are the same way). What a stupid loophole to have overlooked!
    I want to switch the hooks I use into WP’s handling system so that it’s the title (or id, or slug, or url, or querystring, or … anyone have suggestions?) of the post that’s protected, not the url. If the post is the only one being displayed on the page (e.g. that specific page was requested), and the password is required, it’s asked for. If the protected item is part of a list of posts, You can define what’s shown:

    • Either a piece of text you define for all such protected items (e.g. “This is password protected, you must <u>log in</u> to read it.”)
    • Maybe the post’s Excerpt + text, etc.
    • Maybe nothing at all.
    • I’m not decided and want some feedback on this, please.
  4. Create a user-callable function
    If you’ve ever used the Adsense Deluxe plugin, you’ll know how to call it, all you do is put <!– #adsense –> in your post’s text to stick an ad into your content. Seems it would be easy to make a similar call for Password Protection that users can call the same way: <!– #wp-password: required –> (or not-required) etc. I’m not sure how this will work yet. It would allow you to apply the plugin’s protection to a post without having to go into the admin to do it. I like that idea… just not sure how to make it work yet.
  5. Compound/Conflicting rules
    What if you want posts that fall off your homepage to be password protected, while not requiring them for your homepage content – sort of a “you must subscribe to read archives” model. I personally hate sites that do that, but that doesn’t mean I can’t make it work well.
    I’ll have to resolve conflicts between rules somehow anyway. Suppose a rule in the admin protects a certain post, but a <!– #wp-password : not-required –> is found in the post’s text. Which wins? What do you think — which should win?
    The “protect this post but not if it’s on the homepage” idea is similar in nature. Maybe an “inspecific” rule type should be allowed that supercedes all the other rules to say “All the rules above apply unless…” Need to figure that out. Need to also figure out how to present that option in the admin in a way that isn’t confusing as hell. The concept itself is confusing as hell though.
  6. Different Passwords
    So far the system sets 1 password for every protected item. That’s fine if you’re protecting the whole site, or granting access to the whole site. What if different posts are meant for different audiences? What if you’re writing love letters to your girl/boy friend on your site and you want some privacy, but want the rest of your family to be able to read the updates on your dog/kid/siamese twin?
    Seems as long as I’m creating distinctly separate rules, I should be able to attach distinctly separate passwords to them… Or for that matter, specify that in addition to (or instead of) a password for a particular post, access is controlled by assigning specific registered Users to it.

That’s it so far. Feedback is welcome – your suggestions will definitely drive the direction/features/changes I make in this, because I get my giggles out of creating solutions people can actually use.

Join the Conversation

43 Comments

  1. It would be nice if visitors to the page could request the password by filling out a form on the locked page.
    Kind regards
    Ina

  2. Also a possibility to be always logged in (maybe with cookies and a “log out” button). Even if you close your browser and restart it.

  3. I’ve never thought storing cookies permanently on an access-control system was a good idea. But if there’s clamor for it… πŸ™‚

  4. I like the idea of cookies to stay logged in. And of course an option to log out would be great. It is a good option anyways.

    Looking forward to 0.5! πŸ˜‰

  5. @JB I know it sounds a little bit strange, but if you work on your own computer at home it’s sometimes a little bit annoying to log in everytime. Maybe it would be good to have this option onlie for registered blog-user.

  6. I’ve decided to put the cookie expiration date into the admin, so everybody can choose for themselves if cookies expire right away (what it currently does) or go out a specific number of days.

    Then everyone can be happy πŸ™‚

  7. Thanks a lot JB!

    Would it be possible to have in addition to the password-textarea a username-textarea.
    My idea was: If someone is a author at my blog, he can already log-in with his full username and password (which is also the wp-admin login). But if someone will come to the blog as an reader only he could leave the username blank and fill in only the general password for readers from your plugin.
    The advantages are: You don’t have to login twice if you are an author. All registered user would be already logged in to write comments. And still you don’t need to register if you only want to read the blog.

  8. Because my English is unskilled in the person in a different country, the demand cannot be told.
    I know the plug-in that you make to be wonderful. It looks forward to your activity.
    Thank you!

  9. Hey JB,
    Is the already a release date for the new version? Can’t wait to have all this new features πŸ˜‰

  10. No release date yet — But there’s a long weekend coming up and I’ve got no plans. πŸ™‚

  11. Just an update after the holiday weekend:
    I worked on version 0.5 a lot. Most of it works, but there are definitely things still not right.
    Rule processing works, regardless of how many rules you create, but I fear it’s model will lead to problems for users. For example, if I set up:
    For all posts, don’t require a password except…
    1. Paths containing ‘blockme’ require a password.
    2. Paths containing ‘butNotMe’ don’t require a password.
    (auto-rule): Paths containing login.php don’t require a password.

    If your path was “/myblog/post-blockme/butnotme/” no password would be asked for. After comparing the request to the 1st rule, a password is set to be required… but after the 2nd rule, it’s not. And since the 2nd rule came last, it wins.

    Seems like the plugin should let you specify “Paths containing ‘blockme’ require a password, and quit checking further rules.”
    or…
    “Paths containing ‘dontblockme’ don’t require a password, and continue checking further rules.”

    The last “(auto-rule)” rule in the example set above is built into the plugin to prevent asking for passwords on the plugin’s login page, or on WP’s login page. I’m wary that it could be mis-used somehow. I might change it from an auto-rule (processed like the others) to a hard-coded check against the actual script being executed… taking into account your blog’s install path.

    Other things not working yet…
    “Wrong Password” messages on the login page aren’t working – that’s related to redirect code I haven’t found the problem with. Multiple conditions can lead to a redirect (either to the login page, or after the login page to the post you were trying to read, or to the login page with the “Wrong Password” message).

    It’s also getting complicated – so much looping/branching/re-processing that I fear it’s becoming very inefficient, and I might be better off rewriting from scratch instead of trying to bolt-onto/change existing code.

    For now, I’ve had to drop a few ideas from the version I’m working on, just to simplify problems I’ve found:
    Using Post Slug as a field to check terms against is out for now. The hooks I use in WP to catch display of the post only fire before the post itself has been queried, so the plugin won’t know what post slug is being displayed yet.

    Protecting password-protected posts shown in lists/feeds is a problem for the same hook/order reason.

    Post-specific passwords are not in the code I’m working on now. I could add it later, but it only increased the complexity of the code I was working on and I’m having enough “fun” without that.

    Anyway, that’s where it sits right now. If you’re reading this and you’ve got an idea on how to handle any of the perplexing cases I’ve come up with, or think I’m onto the right solution and want to ask questions, please do. πŸ™‚

  12. If i want to place a logout button, how do i do that? can someone help me with this? thanks alot. Email me pls.

  13. There’s instructions in the zipfile you download for placing a logout link anywhere on your site that’ll log users out.

  14. Hi there, I’ve recently started playing with WordPress Password. I appreciate your work to solve this deficiency in WordPress. Currently I have version 0.3 installed. This is the first time I’ve seen a reference to .4 and .5. Is .4 available for download? I am having a few issues with my first attempts at protecting a site. I have “List Mode” set to “include”, but it only protects the first post listed in the input box. Also, the protection is somewhat intermittent. Sometimes it works and others it doesn’t. I haven’t quite nailed down what’s causing it yet. I’d figured I’d check to see if there is a newer version available first. Again, thanks for all the hard work.

    -N8

  15. Hi N8,

    There was a v4, but it wasn’t public… It was pretty specific to s single user’s request, so I’ve gone right ahead to .5

    The “include” option is doing what it ought to. It “includes” protection for the posts/patterns you listed in the box. “Exclude” is supposed to protect everything *except* what’s in the box. Clear as mud, right?

    If you can give me examples of Sometimes working, Sometimes not, I can see what in the code would cause it, but I’m a bit blinded by knowing what I *meant* for it to do, to what loopholes might exist, until it’s been out for a while and people have (as in the case of .3) pointed out what’s not working correctly. I plan to fix the issues I know about in .5

  16. Just for grins, I’ve uploaded preview version of 0.5 tonight, so adventurous souls can take a look, test it for problems, etc.

    A few notes:
    I wouldn’t exactly call this ready for primetime yet. I’ve tested it for a few days, but I was coding as I went, and haven’t run any organized, formal tests against it.

    It doesn’t stop you from showing your protected posts in lists or feeds. I want to address that at some point, but I had to start somewhere simpler.

    I’m tired. It’s late at the time of this post, and it’s quite reasonable to think that there’s a tremendous screwup in there somewhere. Again, this is a *preview* version.

    Let me know if you find bugs/problems/questions… or are just too sensible to download it after that kind of disclaimer πŸ™‚

    http://broome.us/wp-password/wp-password_0_5.zip

  17. I tried to use 0.5 (with wordpress 2.2.2) and I was able to login in my admin-page, but there is a error message if I want to go to the blog:

    Warning: strpos() [function.strpos]: Empty delimiter. in /is/htdocs/XXXXXXXXXXX/www/blog/wp-content/plugins/wp-password/wp-password.php on line 646

    Warning: Cannot modify header information – headers already sent by (output started at /is/htdocs/XXXXXXXXXX/www/blog/wp-content/plugins/wp-password/wp-password.php:646) in /is/htdocs/XXXXXXXXXXX/www/blog/wp-includes/pluggable.php on line 331

    I played around with the rules, but nothing helped.

  18. Thanks for the feedback. I also noticed that the test for querystring type rules is broken, I’ll fix both and re-upload later tonight.

  19. Is there any chance to include a feature like I suggested on the 8/17/2007? I would really appreciate it and it would much simplify the login process for authors and visitors…

  20. Hi Alfons,

    I didn’t build that in because I had questions about it when I was working with it that I couldn’t come up with a good answer to. Here’s the situation:

    The login page that the plugin uses doesn’t do anything. It submits to itself, and if it weren’t for the plugin noticing that the user just submitted a password attempt, it would just display itself again. The plugin’s login page is just a ploy to get the user to submit a password via POST. The plugin intercepts this information and handles the authentication itself and redirects the user – either to the post they were trying to see, or to the login page again with an error message (wrong password).

    That being the case, I didn’t want to be sending people to the regular WordPress login page – because the password fieldname on that page is different, because it DOES do password validation handling, and I didn’t want to intercept and redirect users from the real page away from actually logging in, just because they wanted password-plugin permission to see a post.

    Any suggestions?

  21. Ah ok. That’s interesting…

    Just a new idea from a guy who don’t know much about programming a wordpress plugin πŸ˜‰ :

    Would it be possible to use this plugin to protect everything:
    http://blog.taragana.com/index.php/archive/angsumans-authenticated-wordpress-plugin-password-protection-for-your-wordpress-blog/

    Than use this code to build a individual login page:
    http://www.binarymoon.co.uk/2007/07/wordpress-tips-and-tricks-custom-login-page/

    Than use your code to build a third textarea on the login-page with “just password without username” functionality?

  22. I’ve updated the 0.5 zip linked above with my latest edits.. you should just have to replace the wp-password php file to upgrade.

    I haven’t dealt with the login ideas suggested yet. Still thinking about the Binary Moon wp login page plugin. I couldn’t ever get the Angsuman’s plugin to work for me, which is partly why I made my own. YMMV.

    I’m thinking more along the lines of adding a routine similar to the password test into the plugin that would look for user levels and automatically let through anybody already-logged in to WP. Not sure how WP stores that info yet though.

  23. i like ina’s idea (1st comment). what about adding the possibility to put the “login” form into a page that you can define as “redirect to this page, if user is not “logged in”, so it also uses the blog-design and not the standard wp-login-page-design. (otherwise there is no possibility for normal users to watch any not-protected page, if the main page is protected) would you implement that into your release? about when will you release the new version? thanks for your great work! i like that. πŸ™‚

    regards
    renet

  24. oh and one last thing that would be a very clever addition:

    ignore the password protection, if user is logged in (with the wp-account).

  25. well, sorry, it was not the last thing… but hopefully this will be.

    when i go to my main page and not having entered the passwort already, the following error appears:

    Warning: strpos() [function.strpos]: Empty delimiter. in /www/htdocs/w008171f/gc-bremen/renet/wp-content/plugins/wp-password/wp-password.php on line 649

    Warning: Cannot modify header information – headers already sent by (output started at /www/htdocs/w008171f/gc-bremen/renet/wp-content/plugins/wp-password/wp-password.php:649) in /www/htdocs/w008171f/gc-bremen/renet/wp-includes/pluggable.php on line 341

    this only appears on the main page, on any other protected page the password-protection works. (have a look @ my page)

  26. Thanks for the info. I took the past weekend off for lots of family stuff, but I’ll work on the plugin again this week. I don’t promise on release schedules – I’d disappoint myself (and everyone else) too often. πŸ™ But if I make some headway, I’ll release that work.

    Regarding the password-request idea – I like it, too. What’s the best way to communicate such a request — it’s not a comment… send email from that login page?

  27. yes, i think put a link onto the password-login-page “request password” that leads you to a form that asks for name, email & reason…

    about ina’s idea… will you implement it to your next release?

  28. another thing, if no one has recognized that before, is:

    entering: http://url.to-my.blog// (with two slashes) makes the passwort protection not working, as well… while the error appears when i enter my url with only 1 /, it shows the page, when entering it with 2 slashes, depite having the main page blocked in the configuration…

  29. another thing is, that the password protection is working, when addin no slash at the end of the domain (http://url.to-my.blog – using firefox 2.0.0.7) the error appears only with 1 slash (http://url.to-my.blog/) … i found some topics in the wp support forum about that issue. just search for “headers already sent” …

    sorry for flooding your comments, i’ll post further requests in the wp plugin forum.

  30. Renet! That’s not flooding, that’s valuable feedback! I like it πŸ™‚

    My week is ruined right now… At work we’re going through a sharply focused seminar on database performance tuning and I’m working from 8:30am till 10pm while logging/tuning/etc.

    I’ll incorporate your suggestions into the next release, but I don’t know when that’ll be yet.

  31. hmh maybe you can tell me what code is relevant for the pw-form so i can put it onto a wp-page myself? i’m working to fix the “headers already sent” error myself…

  32. i don’t know why, but the error i quoted (comment no. 27) only appears when i try to open my blog the first time after starting my browser… Oo

    the error only appears if i try once again (without restarting my browser) and didn’t enter the password the first time… weird

  33. oh dammit dammit dammit.. i dont know whats going on with me.. usually i dont make so many mistakes.. the error DOESNT appear when i try the first time after starting my browser, only the following times it appears…

  34. Ok, so it’s somehow related to existence of a session-length cookie. Good to know.

  35. Hi, I really appreciate your plugin (v3), which seems (fingers crossed) to work fine with WP 2.3. Server authentication seems to be up the spout with 2.3.

    I would appreciate the possibility to put my own message to people who have to log in, or more politely, people who are excluded. Could you put a text string option on the options page?

    I’d like to put something like: “this site is not ready for prime time yet, so it’s password protected till it’s ready”.

  36. I’ll second that recent idea. This would allow me to say something like “Enter the first name of my son to get in!” or something without having to hack the login.php file!

    Also, it’d be great to allow more than one working password. Using the example above: if I had 4 sons, I could allow any of their first names to be typed in to gain entry to the site.

  37. I’ve noticed a slight conflict with the WPhone plugin (which is fabulous, btw). That plugin gives the option of using the mobile admin interface upon login, and since you’re sharing some code with the WP login, it also shows up on your front door password check. Check out popptopia.com for an example.

  38. I tried your site, and maybe I’m just dense today… it’s known to happen…. Does the fact that WPhone and WP-Password “interact” present a problem?

Leave a comment

Your email address will not be published. Required fields are marked *