8000 Improve handling of active URLs (esp HTTPS construction) by totten · Pull Request #236 · civicrm/cv · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Improve handling of active URLs (esp HTTPS construction) #236

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 9 commits into from
Feb 20, 2025
Merged

Improve handling of active URLs (esp HTTPS construction) #236

merged 9 commits into from
Feb 20, 2025

Conversation

totten
Copy link
Member
@totten totten commented Feb 12, 2025 •
edited
Loading

Overview

Improve the integration between cv, its URL inputs, and the common $_SERVER variables. Specifically, if you give the --url option, then it will set variables like HTTP_HOST, HTTPS, and SERVER_PORT

$ cv ev --url=https://example.com:4444 'echo $_SERVER["HTTP_HOST"];'
example.com:4444

$ cv ev --url=https://example.com:4444 'echo $_SERVER["SERVER_NAME"];'
example.com

$ cv ev --url=https://example.com:4444 'echo $_SERVER["SERVER_PORT"];'
4444

$ cv ev --url=https://example.com:4444 'echo $_SERVER["HTTPS"];'
on

By setting these server-variables, we should give better hints to any URL-generating functions in CMS or Civi.

The older options --cms-base-url and --hostname are retained as unpublicized aliases. The new --url option is the combined+expanded replacement.

Example Problem

In civicrm/civicrm-core#31271, @seamuslee001 mentions the use-case where one installs a WordPress site with an HTTPS address:

cv core:install --cms-base-url='https://example.com/'

This URL is properly recorded in CIVICRM_UF_BASEURL. However, when calling APIs to generate URLs (such as WP's plugin_dir_url()), those functions may sometimes compose http:// URLs even though the user indicated that https:// is valid. (And if https:// is valid, then it really should be used.)

For plugin_dir_url(), the reason is that WP is inspecting the active request ($_SERVER and its properties, HTTP_HOST, HTTPS, SERVER_PORT, etc); these don't include any HTTPS flags, so we get basic HTTP.

It seems that we should provide stronger direction on how these server-vars behave in CLI context.

Before

  • All cv commands accept input from --hostname example.com and env-var HTTP_HOST=example.com.
    • These do feed into $_SERVER, but they don't indicate whether HTTPS is supported.
  • In cv core:install, there is also an option --cms-base-url which accepts a fully formed URL.
    • This conveys more information (including HTTPS), but it doesn't feed into $_SERVER.
  • If you do not specify a URL via --hostname or HTTP_HOST, then $_SERVER is devoid of information about HTTP/SSL. Consequently, you are liable to emit http:// URLs and localhost URLs.

After

  • The old options --hostname and --cms-base-url are deprecated. They function as aliases for --url.

  • All cv commands accept input from --url (-l) and env-vars HTTP_HOST, HTTPS, SERVER_PORT.

    • This feeds into $_SERVER, and it also indicates HTTPS support.

    • As before, you can give a bare hostname -- but you can also give a fully formed URL.

      cv ev 'echo $_SERVER["HTTP_HOST"];' --url=example.com
cv ev 'echo $_SERVER["HTTP_HOST"];' --url=https://example.com
cv ev 'echo $_SERVER["HTTP_HOST"];' --url=http://example.com

      If the given URL is https://, then you can expect most URL-composition to enable HTTPS.

      This works for core:install (CMS-first boot) and all regular commands (Civi-first or CMS-first boot).

    • The new option is shorter and easier to type. It also gives a nod to folks who use wp-cli or drush:

      Cv Options Similar To Comments
      cv --url=XXX wp --url=XXX In vernacular speech, "URL" is common.
      cv --uri=XXX drush --uri=XXX Unpublicized alias. "URI" is less vernacular.
      cv -l XXX drush -l XXX

  • If you do not specify --url (or similar env-vars), then the behavior varies:

    • If Civi boots first, then it populates $_SERVER using CIVICRM_UF_BASEURL. (You will get HTTPS if the BASEURL has HTTPS.)
    • If CMS boots first, then it populates $_SERVER using http://localhost. (This doesn't seem ideal -- it will still tend toward HTTP. But it is the status-quo, and it's trickier to find a fix.)

@totten
Copy link
Member Author
totten commented Feb 20, 2025

Rebased.

I've done some light testing on Drupal multisite. All seemed good:

  • It successfully installed new subdomains.
  • And if you called with --url=subdomain.example.com, then it loaded the corresponding civicrm.settings.php.
  • As expected, --hostname still works as well (just with a deprecation notice).
  • When using the @site aliases, it still worked.
    • If the alias specifies the deprecated --hostname option, then it works (with a warning).
    • If the alias specifies the new --url option (or the HTTP_HOST env-var), then it works.

Test failures are unrelated/external.

@totten totten merged commit 32f4aa6 into civicrm:master Feb 20, 2025
1 check failed
@totten totten deleted the master-wp-ssl branch February 20, 2025 01:14
@totten totten mentioned this pull request Mar 6, 2025
Merged
@totten totten mentioned this pull request Apr 4, 2025
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@totten
0