[wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

Fri Oct 28 22:16:12 UTC 2011

Correction, it doesn't do it to urls in the content, but your rss feeds urls are absolutely post processed

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Marcus Pope
Sent: Friday, October 28, 2011 5:15 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

Otto, I appreciate the moderated tone.  I will respond in kind.

Sunrise.php solutions will not fix the multisite problem, unless you intend to do database updates on every page access.  And given the concurrent nature of the web this will literally be impossible without using a processing stack in a non-grid environment.

The onus is still on you to provide a security concern with accessing a site from either the IP address or the DNS name.  Accessing the wrong IP or DNS name is equally possible, and the reason you are not allowed access to NAT configurations and changing DNS entries in corporate environments is specifically to prevent those man in the middle attacks that allow you to steal passwords (in the case of wordpress only the encrypted form.)  You may think those practices don't solve anything, but it isn't germane to my point.  There is no inherent security flaw to accessing a site via it's IP address or DNS entry.

But the key point you miss, the fundamental flaw in this discussion is this:

What? Where? Why? Absolutely NO processing of my URLs happens in any of my feeds. That violates the whole concept.

Wordpress processes your URLs on every single request, for both content and for system internals.  The very premise of using is_ssl() to change http to https or vice-versa is to post-process your urls.  And there is no solution to that without using only one or the other and directly modifying core files.  Until then your site, your feeds, and your content are post processing every single url that every reaches a browser, book, email, rss feed or xml file for every single request.

In my world that would never happen if I could stop it, and in my world doing that is wrong.

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Otto
Sent: Friday, October 28, 2011 4:58 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

On Fri, Oct 28, 2011 at 4:23 PM, Marcus Pope <Marcus.Pope at springbox.com> wrote:
> Otto, it's not that simple - changing WP_SITEURL and WP_HOME doesn't fix the problem, wordpress admin will still pull content from other sources.  Additionally, a problem you have ignored from email 1, and WP_SITEURL and WP_HOME are not even evaluated in Multisite setups. They are ignored.  This does not work.  The effort I put into my plugin shows what is required to make it work for 99% of the problem domain and it only works in single site installs.

Multisite is indeed special, I grant you that. However, it's quite easy to make yourself a custom sunrise.php file and use that to fiddle with the multisite variables all you like.

> 1.  You still don't get the export content issue.  If you host your content (different from exporting it away from your host) you can use root-relative urls 100% of the time no exceptions, every browser every mobile device will work, it's part of the http protocol standard.  When you export your content, like an rss feed, or email, or xml export, you can then process the content, and only then, which will save you all this hassle of dns tricks, search / replace scripts, wp filter and constant hacks.

Okay, I see what you're saying. But here's the thing: If you have content with absolute URLs in it, then you never need to process the content for "exporting" at all. It just works. Absolute URLs work everywhere. That's sorta the point.

> 2. You solve the export problem with one function.  You don't have to change the database, you feed what is in the database through that really simple filter and you're done for that half of your content.  As it stands wordpress filters all of your url content in every instance of its usage.  You don't need to keep those absolute urls in your database I promise millions of websites do it without any issues.

I don't "need" to keep the absolute URL in the database. I *WANT* to keep it there. Absolute URLs are better than relative URLs. They are direct links to what they are supposed to link to. They are unambiguous and not open to interpretation based on the context in which they are being displayed. That's why they're better.

WordPress doesn't filter my absolute URLs at all. It has no need to do so, because they are absolute and unchanging. They pass right through and come out on the webpage, in my feed, pushed to my social-networks... everywhere they go, they point to the same place and they-just-work.

> 3. Administering sites from multiple URLs is only part of the equation, and just because it doesn't make sense to you doesn't mean that it is stupid or shouldn't happen due to very legitimate reasons in reality. ...

As Mika pointed out, yours is a fringe use case. And there's nothing wrong with that, fringe cases are commonplace, but they are all different and not-the-norm. Having a plugin to help your use case work better is great. But it should probably remain a plugin.

> 4. If you think convincing the military, pci compliant organizations and the rest is just as simple as standing up and shouting you're stupid, ...

While my security clearance hasn't been renewed in a while, I did have one and I have worked on DoD funded projects. So I do know wherefrom I speak here. And yes, telling a top-brass General that the people he's been listening to up-until-now are idiots was indeed a rather fun experience.

> the extreme necessary value and purpose of why their NATS are setup that way. It is NOT STUPID, it's IMPORTANT.  These are not mistakes they are solutions to a world of security problems and will not go away because you don't like it.

No, they will go away because a) they rarely solve anything, b) usually they're implemented badly (often, yes, by idiots), and c) they cause incompatibility problems up the wazoo.

Look, I get it. I've been there in that world. I've been through that living corporate hell and back again. In the long run, you're not thinking politically enough. I know, we just want to be developers, but the bottom line is that when an organization makes it harder for you to do your job, and justifies it with nonsense excuses (there is NO valid security related reason to set up a NAT in the way you described. Internal DNS resolution is a totally solved freakin'
problem), then you might consider re-evaluating your relationship with them. Sometimes you have to drop customers, or get customers to see the light of day. It can suck, but it can also be rewarding.

> Other "sucky" frameworks do not violate these principles...

That depends on your definition of "principles". I would argue that their adherence to a rigid set of fundamentally incorrect and ill conceived notions is what makes them suck.

There's good ideas, and there's bad ideas. I reserve judgment on any idea *to myself*. I judge. I do not assume that 1000 other people doing it one way means that they are doing it the right way.

> 5. What security issue exists if I access wp-admin from 127.0.0.1 (or 
> its production equivalent)?  (the answer is there isn't one.)

If you access a site from an incorrect wrong URL, then there is the possibility of having your admin cookies snatched unless you're in a tightly controlled environment. Come and log into your wp-admin from my network, even with SSL, and watch me log in as you immediately afterwards. Unless you have your domain tightly controlled and secured with an SSL certificate, which you can verify, you can never be sure about a potential man-in-the-middle attack.

> You try to say it won't work because we'd have to process the crap out of the data, but then you say the proper way to do it is to process the crap out of the data when you move environments.

Yes, that is exactly correct. Because you shouldn't be moving between environments that bloody often.

> You try to say with rss feeds (a clearly defined entry and exit point in the wordpress core) that it would break, yet we currently process the crap out of those absolute urls in rss feeds as it is to prevent it from breaking with absolute urls.

What? Where? Why? Absolutely NO processing of my URLs happens in any of my feeds. That violates the whole concept.

> The ultimate case is there isn't a scenario in which relative root 
> urls are deficient to absolute urls

Relative URLs are deficient to Absolute URLs because Absolute URLs actually work, and relative ones do not work at all outside of the webpage context. How can you possibly be still getting this so fundamentally wrong?

-Otto
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers