Issues when forcing logins to view map on external server (with workaround)

[ServError]

When disabling the internal webserver in favor of apache and requiring login to view the map (and chat), I'm finding that the logins are not saved, requiring everyone to re-register every time they want to view the map. I also find that sometimes I get a "configuration error" popup on the client when navigating away from one map to another, and then trying to return to the original map.

What I am not sure of -

Whether or not this can be replicated on the internal server If my windows based server is denying access to wherever logins are stored

What I can see -

The dynmap_login and dynmap_reg files are being written to properly (in reg, all the login information is in comments, and in login, I see my users in pendingreg

My Workaround -

By opening dynmap_login and focusing on the $pwdhash array, I can see that that's where the error lies, because it is never being updated. By copying the password hash from dynmap_reg into that area in a standard array format ("username" => "hash",) on every line, logins for that user become permanent.

[mikeprimm]

What are the settings in your configuration.txt - it sounds like the plugin is never finding or processing those files (the dynmap_login.php comes from the plugin, and produces its content based on seeing the results of the registrations in dynmap_reg.php). The register script only cleans up register results when it notices that the plugin has accepted them and made them permanent (by adding them to the $pwdhash and removing them from the $pendingreg).

[ServError]

A couple of things to add (followed by my configuration.txt). It seems that the dynmap_login is wiped and not repopulated on server restart. Also, the issue I mentioned about "switching maps" refers to moving from my survival server's dynmap to my creative and back in google chrome (just thought I should clarify).

My configuration.txt (for the survival server) is available at http://pastebin.com/rbvd0JmE

I've been using dynmap for a long time, and just yesterday decided to delete my configurations, let new defaults generate with all the new options that you've added, and adapt them to my setup.

[mikeprimm]

That would be consistent - the dynmap_login.php reflects the logins configured by the plugin, so if the registrations are never processed, it will write the logins that it has accepted. The main thing to check is whether or not the dynmap_reg.json file is readable by the user ID running the Bukkit server - if we can't read that, the rest of this is pretty much what I'd expect.

[ServError]

Hm, I seem to be missing a dynmap_reg.json file altogether.

[mikeprimm]

Its dynmap_reg.php - gets created when register.php is used.

[ServError]

Yep, that seems to read and write just fine. As I mentioned, users are getting stored into it properly in its commented segment just as that code in register.php is meant to do, but my educated guess is that the entire if(!empty($lines)) statement and anything deeper isn't processing.

Edit - Well, no, actually I take that back, that code does seem to be doing it's job. My output in dynmap reg is

<?php / servili007==XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX / ?>

[mikeprimm]

That part doesn't really DO anything - its just a way to clean up the completed registrations: the issue is the fact that the plugin is not seeing the completed registrations in dynmap_reg.php, and isn't updating the real login store (which is actually webauth.txt in the dynmap directory) and the published login data (dynmap_login.php). If either of those don't happen, the login registration was never really completed.

[ServError]

yep, I just realized that, sorry. I'll keep playing with it and post whatever I find.

Edit - And I do not have a webauth.txt in my dynmap directory

[mikeprimm]

What are you seeing from dynmap in the server.log (during startup and anything else)?

[ServError]

I'm not seeing anything out of the ordinary. I tried changing the error reporting level as well and running through the usual process of registering a user, but got no feedback.

[mikeprimm]

Can I see the server.log details for the dynmap startup?

[ServError]

Sure - http://pastebin.com/4bsF8JLu

I am seeing an unknown command error, though I'm not sure what that is or if it's related.

Edit - Nope, the unknown command persists even with dynmap disabled, but NOT if bukkit is disabled

[ServError]

just updating to say that I can reproduce this if I make logins optional

[mikeprimm]

If logins are disabled, your config.js is incorrect (the URLs are only set to be set to the scripts when login is enabled - anything else is invalid).

Edit: Oops - you said optional, not disabled.

Give the updated 0.36.2 release build a try - fixed several security issues

[ServError]

hmm, still getting the same problem. I'm still trying to play around with things until I can figure something out.

what should the contents of dynmap_reg.php and webauth.txt look like upon successful registration?

[mikeprimm]

webauth with have a line for each registered user, with a user. and a value representing the password hash, as well as a random salt attribute: this file is the heart of the security configuration - the other files are only in support of the registration process via external/json mode (dynmap_reg.php), or publishing the external/json version of the data from this file (dynmap_login.php). webauth.txt (which is found in plugins/dynmap) HAS to exist - but doesn't get created until the first time a registration is completed. What you're describing is what I'd expect if you'd configured login support in the config.js file, but not in configuration.txt (that is, if either it was not configured with the JsonFileUpdateComponent, or if the 'login-enabled' setting were not 'true').

[ServError]

A couple of observations. I edited the configuration.txt and config.js to use the internal server, and re-enabled the internal webserver. The login system worked fine like this, with webauth.txt being generated and populated. Once reverting my settings back, the saved webauth.txt is still reads properly for registered users, but as always, nobody can save their new registrations.

Could this be something as simple as write permissions being denied to the PHP script? I know that from time to time people complain about php scripts running under windows being denied write permissions in directories that are vastly different from where they reside.

[mikeprimm]

Only directory the PHP scripts write to is their own directory (standalone) - but the written files do need to be readable by the bukkit task (if we couldn't read the dynmap_reg.php, for example, the behavior would look like what you're seeing). Also, the sendmessage.php would not work (since that basically does the same thing - but writes the dynmap_webchat.json file).

[mikeprimm]

Found an issue - give latest 0.36.3 development build a try.

[ServError]

Still running into the same issue, was really hopeful but to no avail. I'm running PHP 5.4 by the way, which I imagine doesn't matter, but I thought I'd note that.

I'm sure that either I'll find out what's configured incorrectly on my system (since dynmap seems to be setup properly) or something will develop with the code (even if you don't specifically find the issue, it could end up being one of those situations where it just works a few versions down the road, no rush anywho)

[mikeprimm]

Not sure what to tell you - latest code is working fine with the new fix: make sure you updated all the standalone files, and you might want to clean out any old dynmap_reg.php or dynmap_login.php files before restarting.

[ServError]

Okay, I cleared out those files, updated to 1.2.5 along with bukkit 1.2.5, restarted the machine (since it had been a while and I had played with the PHP installation files in that time), and viola, no more problem.

Thanks a bunch for all the support!

[mikeprimm]

SWEET- you had me worried on the last one :) Please let me know if anything else crops up - the security stuff is still quite new, so I don't doubt that there are some other issues floating around.

[ServError]

Hehe, sounds good. When I saw the new security features in the changelog I got all giddy since I was about to switch my server to whitelisting and wanted an easy way to only let specific people on. Thanks again, you're plugin is always awesome and up to date!