Forum Replies Created

Viewing 7 replies - 1 through 7 (of 7 total)
  • Also having this issue in WCS v1.24.2. It appears there’s a pull request that resolves this, so I imagine the update that incorporates it should just have the standard WordPress plugin update fixing the issue. ??

    Thread Starter Mopquill

    (@mopquill)

    This is still unresolved, though I will report back if I discover a solution.

    Thread Starter Mopquill

    (@mopquill)

    I did not do anything to make the login form show on the front end. I outlined above what I did; I didn’t do any extra steps. I literally installed it and it’s doing this. As I mentioned, running into this issue on another site, I made a sample site and ran into this right away. I didn’t change the site URL or WordPress URL. wp-login.php also shows the login form. And before you ask, my Index options are not set to use wp-login.php.

    I actually came here tonight (on my free time) per request of a user that asked me via email if I had left the company or something like that because I used to be very responsive in this forum.

    …and of the posts of people asking for help, you chose to engage me based on an off-handed comment? o.o

    I don’t know what to tell you, but Apache runs PHP as a basic module under the user www-data — standard Debian stuff. And I definitely consider Debian to be the most secure distro for web servers. Anyhow, individual users own their files (because if www-data owned them, they’d get the 7, which would be the same as having them as 777 relative to a web user being able to write files). I mean, just throw up a Debian machine — you don’t need my server config for that. But if the server can write to them, *that* is a security issue. You don’t want the server having the permissions to write to files that have to do with config, because then if there’s any hole anywhere, they can write to them. That’s why the stuff in wp-uploads is typically pictures and whatnot where it wouldn’t cause harm.

    Dude, if you’re claiming the database isn’t safe, then they could just hijack whatever they want, log in, and change all the settings. The database is way safer than a world-writable file in a web-facing directory. That’s like… security 101. I have opened those files, and an exit line shouldn’t be all that stands in the way of your configuration printing, especially when that setup makes it so mine can’t even write — hell, in the name of security, if for some reason the plugin *can’t* write to the files, it should be falling back to the database anyhow.

    First off, that was just a tongue-in-cheek comment. It’s kind of depressing that you’d answer that within a week, but take a month to reply to the issue itself.

    The server’s mine. It’s configured correctly, and your suggestion as to *why* this is happening is incorrect. I can tell you that if the permissions on those files are not 777, you can’t do things like manually approve core integrity issues, save last-logins (mine are blank despite hundreds of attempts at using the recent WordPress XML-RPC exploit), trusted IPs, etc.

    In any case, I’ve really got to wonder why so many people are having this issue — why store these settings in PHP files in wp-uploads (which is just a bizarre way to do it anyhow) where they can be public-facing at all? Why not just put them in the database? It’d be faster, more secure, and you wouldn’t have to worry about write-errors, or their contents being viewed.

    I have the same issue. It has something to do with certain files (or the whole directory) not being set to 777 in wp-content/uploads/sucuri — which is generally good security policy. And here I thought this was a security plugin. ??

    Mopquill

    (@mopquill)

    Yeah, I just developed an mobile plugin for a different software that didn’t have one, and then I came to good ol’ WordPress, and had to do the same thing. But this is WordPress we’re talking about- why reinvent the wheel? Wapple was the first thing that came up, and they don’t mention -anywhere- anything about keys or accounts or money. They just tell you about all the features they have, and this is a plugin for a free, open-sourced blog software.

    So, I install it, and I need a dev key. “Okay”, I think, “this is probably an anti-spam measure; I can’t blame them at all.” and then I find out they’re going to advertise on content that doesn’t belong to them to do something that some quick PHP and a list of user agents can do by themselves? All of this on a free blogging software? Is the irony lost on them?

    Anyhow, I don’t know if I’d quite call them capitalistic pigs, but, I’m certainly never happy with people trying to bring capitalism into open-source. Especially when it’s one facet of it. If everyone had their way, most WordPress sites would have like, six copyrights for people/groups that have nothing to do with the content generation of the site, and the owner would be paying several different groups monthly just to be able to use their plugins on a free platform.

    It’s all just nonsense. Have some decency, Wapple. :-/

Viewing 7 replies - 1 through 7 (of 7 total)