WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#8927 closed enhancement (fixed)

allow turning off 'calling home' even _before_ install

Reported by: jidanni Owned by: jacobsantos
Milestone: 2.8 Priority: lowest
Severity: trivial Version: 2.7
Component: HTTP API Keywords: dev-feedback has-patch needs-testing
Focuses: Cc:

Description

Gentlemen, I would like to talk about a general concept: installing a
piece of software without it going behind your back and "calling home"
to mother, or lighting up the modem lights by calling anywhere on the
Internet.

I remember when I used MS Windows, who knows what clicking "install
this software" would do.

Compare that to a MediaWiki install, offline, online, all the same, no
initiating HTTP requests.

I agree that the default install of WordPress should probably act as
it does currently, but there should be a way to also install without
all those attempted HTTP fetches, without having to turn off one's
connection.

Anyway, apparently I can one by one turn off options, to make
WordPress "speak only when spoken to", i.e., no track/ping backs, etc.
Also see Bug #6897: Magpie cache needs looking at.

But there is no way to stop all the fetching right from the install.

Attachments (1)

8927.diff (16.2 KB) - added by jacobsantos 7 years ago.
Has HTTP API cleanup and adds capability to block requests through use of constants.

Download all attachments as: .zip

Change History (21)

comment:1 @jidanni7 years ago

  • Version set to 2.7

Ah, the concept sounds rather like this
plugin
which I shall learn about soon.

However plugins should be to enhance WordPress, not disable undesired "enhancements".

comment:2 @jidanni7 years ago

I see, it is not a plugin, but a replacement dashboard, three years
old too.

Anyway, all I'm saying is there needs to be a choice one encounters
upon installing WordPress, that allows one to opt out of all those
network connections from day one even before they start for the first
time. Just like MediaWiki would never think of connecting, (but
MicroSoft would!)

Or they could just opt-in to checking for newer releases.

The way it is now, there is no choice to turn such things like that
off. Totally MicroSoft.

P.S., Trac has no choice to set version = 2.7.1.

comment:3 @jidanni7 years ago

  • Milestone 2.8 deleted
  • Priority changed from normal to lowest
  • Severity changed from normal to trivial
  • Summary changed from calling home during install to allow turning off 'calling home' even _before_ install
  • Type changed from defect (bug) to feature request
  • Version changed from 2.7 to 2.7.1

Even if one installs sophisticated tools like
http://wordpress.org/extend/plugins/core-control/
you will have to admit WordPress is booby trapped in that in order to
install that plugin, one must go to the Dashboard, and in so
doing, one gets a mouthfull of HTTP requests sent even before one can
reach for the 'screen options' to turn them off. You just can't win.

(OK, TRAC has 2.7.1, way at the bottom. #9159.)

comment:4 @DD327 years ago

  • Component changed from Optimization to Administration
  • Keywords dev-feedback added
  • Milestone set to 2.9
  • Version changed from 2.7.1 to 2.7

See also: #4011 (Add Proxy Support)

Simply disabling all the transports does cause certain functionalities of WordPress from working (ie. cron).

WordPress Does need a method to define proxy servers for HTTP requests And a constant to define lack of external http access. I might consider spending some time doing it myself for 2.9 if no-one else does it before then.

comment:5 @DD327 years ago

  • Component changed from Administration to HTTP
  • Owner anonymous deleted

comment:6 @jidanni7 years ago

Firstly I am very happy to discover the core-control plugin,
demonstrating that not everybody likes the joyride "teen phone rage"
of HTTP requests (
http://thread.gmane.org/gmane.comp.web.wordpress.devel/26096 ).

However, perhaps there should be an integrated approach. Currently it
seems one can "jack up junior's car so its wheels don't touch the
ground", but one cannot "ask him to give back the keys, nor even turn
off the gas".

I.e., one can put roadblocks on the HTTP transports, and even hooks so
nothing happens when the cron jobs are run, but one cannot even
disable the ticking time bombs of the cron jobs themselves!

There should be a way to eliminate all waste: no sending the mailman
out with no letters to deliver, etc.

Also, we who feel uncomfortable about wordpress "calling its friends
while we aren't looking", "even if they are of the highest pedigree",
are also uncomfortable about having to install a plugin to stop such
behaviors.

In fact, if I was able to easily (without hacking anything),
my (Mom's) site
http://abj.jidanni.org/articles/ , would be fine with 0 plugins, and
just 1
theme, http://jidanni.org/comp/wordpress_jidanni_theme.zip .
(But I can't delete the built-in two themes, #8678.)

Anyway, though core-control is very pretty, I would like to just set
some define()s in wp-config.php to disable various things, no plugin
nor clicking needed. Thanks.

@jacobsantos7 years ago

Has HTTP API cleanup and adds capability to block requests through use of constants.

comment:7 @jacobsantos7 years ago

  • Owner set to jacobsantos

comment:8 @jacobsantos7 years ago

  • Keywords has-patch needs-testing added

Yeah, implementation in patch should do this. Needs testing.

comment:9 @jacobsantos7 years ago

  • Type changed from feature request to enhancement

comment:10 follow-up: @jacobsantos7 years ago

The implementation isn't that dangerous, unless it breaks execution, I think it can be safely applied to trunk.

comment:11 in reply to: ↑ 10 @westi7 years ago

Replying to jacobsantos:

The implementation isn't that dangerous, unless it breaks execution, I think it can be safely applied to trunk.

Looks good for trunk testing. Only a couple of poetic changes required ;-)

comment:12 @westi7 years ago

  • Milestone changed from 2.9 to 2.8

comment:13 @westi7 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [10625]) Add support for blocking all outbound HTTP requests. Improve HTTP Api phpdoc. Tidy up the poetry. Fixes #8927 props jacobsantos.

comment:14 follow-up: @jidanni7 years ago

Looks good. OK, I see you all have taken the "lock the liquor store" (seal
off HTTP access) approach. However that still leaves plenty of
teenagers (processes that wish to use HTTP) roving around outside
hoping for access... but I suppose that's how society is.

But wait, my "gold standard test" is: starting from a vanilla install,
all the way even including browsing the dashboard (currently (2.7.1)
booby trapped to download RSS even before you can reach for "screen
options"), can I avoid one single download?

* You block external URL requests by defining WP_HTTP_BLOCK_EXTERNAL
* in your wp-config.php file  and this will only allow localhost and
* your blog to make requests.

Sorry I'm still using 2.7.1, but looking at the new code,
aren't "localhost and my blog" the ones making those RSS etc.
requests on the Dashboard?

By the way,

* The constant WP_ACCESSABLE_HOSTS will allow additional hosts to go through for requests. 

that would be good for 'Block many, but let through a few', but I'm afraid you need one further variable for those who wish to 'Block a few, but let through many'.

comment:15 @jidanni7 years ago

  • Cc jidanni@… added

comment:16 in reply to: ↑ 14 ; follow-up: @jacobsantos7 years ago

Replying to jidanni:

Looks good. OK, I see you all have taken the "lock the liquor store" (seal
off HTTP access) approach. However that still leaves plenty of
teenagers (processes that wish to use HTTP) roving around outside
hoping for access... but I suppose that's how society is.

What other approach is there? Hide all of the liquor or remove the liquor from the store every night?

But wait, my "gold standard test" is: starting from a vanilla install,
all the way even including browsing the dashboard (currently (2.7.1)
booby trapped to download RSS even before you can reach for "screen
options"), can I avoid one single download?

I don't understand, WTF are you talking about? If you want to disable HTTP API, you do so in the wp-config.php, you can do this before you even install WordPress or before you enter the dashboard.

* You block external URL requests by defining WP_HTTP_BLOCK_EXTERNAL
* in your wp-config.php file  and this will only allow localhost and
* your blog to make requests.

Sorry I'm still using 2.7.1, but looking at the new code,
aren't "localhost and my blog" the ones making those RSS etc.
requests on the Dashboard?

No, sorry, that should read, "Will only make requests to localhost and your blog host."

By the way,

* The constant WP_ACCESSABLE_HOSTS will allow additional hosts to go through for requests. 

that would be good for 'Block many, but let through a few', but I'm afraid you need one further variable for those who wish to 'Block a few, but let through many'.

Yeah, you know, a plugin can hook into it and add theirs. I suppose the whitelist is more security minded, but a lot more work when you have a great deal. However, it was not forseen that there would be many hosts that you will want to allow. Preventing only a few won't exactly protect you. If you want to allow more, then you can do so. I suppose, if you have plugins, you will need to add exceptions for them, for the ones you want to let through.

Actually, it would be extremely easy to add the ability for allow, deny constants. I don't forsee myself attempting that at this moment nor in the near future.

Actually, ACCESSIBLE hosts is misspelled and needs to be corrected (don't want it to end up like HTTP 'referer' (sic)), so I'll fix that and add allow and deny. Not this week, but soon.

comment:17 in reply to: ↑ 16 @jidanni7 years ago

Replying to jacobsantos:

No, sorry, that should read, "Will only make requests to localhost and your blog host."

OK, I'm happy. Thanks.

As far as whitelists/blacklists go, all I know is I've seen too much software that was missing one of the pair, causing later regret...

comment:18 @jacobsantos7 years ago

It is not expected that this will be a widely used feature. If it comes up that it is needed, then it can be added later with little regret.

comment:19 @DD327 years ago

that would be good for 'Block many, but let through a few', but I'm afraid you need one further variable for those who wish to 'Block a few, but let through many'.

That isn't a common use-case, Its a bit more common for boxes to be on lans and have NO external access, or only access to certain servers.

Its extremely rare for someone wanting to (on a software level) block access to a select few hostnames.. In those cases, Its better off implemented at the network level.

I do not think WordPress as a whole needs to support 'Block few, Allow many' It benefits the end user little, 'Block many, Allow few' on the other hand, Is a functionality which has been needed for enterprise-level installs for awhile now.

While i agree it wouldnt take much to add it in, I just.. Question the actual need for it, The only reason i see people using it would be to block api.wordpress.org and the plannet feed.. Both of which is a stupid thing to do, They're much better off attacking it at a higher level than the HTTP request stage.

But wait, my "gold standard test" is: starting from a vanilla install, all the way even including browsing the dashboard (currently (2.7.1) booby trapped to download RSS even before you can reach for "screen options"), can I avoid one single download?

Thats a separate issue really, That once you turn it off, The RSS result stays around in the cache. I highly suspect that this will be fixed in 2.8 with the RSS remodeling and widget(dashboard included) modifications. The fact that it downloads the feed once should be ignored, If You don't want WordPress to make any external connections, you'll have defined the constant during the setup, Blacklisting will not help in that instance.

comment:20 @westi7 years ago

We don't need a blacklist here.

A whitelist is fine for this feature.

If you want to limit where something can connect to then you should be explicit it is much simpler to get the behavior you require then.

Note: See TracTickets for help on using tickets.