Make WordPress Core

Opened 12 years ago

Closed 7 years ago

#20253 closed enhancement (wontfix)

SSL login in custom port

Reported by: rseabra's profile rseabra Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Permalinks Keywords: has-patch ssl https
Focuses: Cc:

Description (last modified by dd32)

From my blog article, http://blog.1407.org/2012/03/18/log-into-wordpress-with-ssl-on-custom-port-if-needed/

In order to login into WordPress with SSL you just need to add the following to wp-config.php:

    define(‘FORCE_SSL_LOGIN’, true);
    define(‘FORCE_SSL_ADMIN’, true);

But that redirects you to https://www.yourDomain.org/. What if you need to redirect into https://www.yourDomain.org:8443/ ? What then?

Well, the following patch will allow you to add a property called CUSTOM_PORT which you will define as your desired port. In case of my small example, 8443 like this:

    define(‘CUSTOM_PORT’, 8443);

Attachments (1)

wordpress-custom-port.patch (539 bytes) - added by rseabra 12 years ago.
custom port for ssl patch

Download all attachments as: .zip

Change History (10)

@rseabra
12 years ago

custom port for ssl patch

#1 @rseabra
12 years ago

Yes, I know my description has a bug with the port number, but that's just "description" and I only noticed it after creating the ticket. My blog article has it fixed :)

#2 @dd32
12 years ago

  • Component changed from Security to Template
  • Description modified (diff)

Quick thoughts:

  • Won't work when installed in a subdir (site url returns http://something.com/wordpress/)
  • is_ssl() may not reconise the alternate port in some configurations
  • not all ssl links are generated through that function (unfortunately), there are a number of cases of code such as: wp_redirect('https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']); (wp-login.php)
  • This could also be achieved using a filter (other than the above case where url's aren't generated with filtered functions)
  • CUSTOM_PORT would be better off named SSL_PORT or similar.

(Pulling out of the Security component since it's not a security issue in WordPress)

#3 @rseabra
12 years ago

Thanks. I thought it would fit in the security part as it was an improvement to security.

Hmms, I see that it will take a much deeper code investigation in order to pick all of that than what I probably have time for.

The reason I thought of not binding it to "SSL_PORT or similar" was that maybe this could evolve to non SSL ports (eg, just http but on another port).

I don't see why it wouldn't work in a subdir, though, as it adds the port before the path component of the url, if I understood the code correctly.

Anyway, I'll try to tackle those issues, but for the moment, it WFM ;)

#4 @Ipstenu
12 years ago

I don't see why it wouldn't work in a subdir, though, as it adds the port before the path component of the url, if I understood the code correctly.

Give it a shot and you may see. But remember to also test having WP in a subdir but running out of root.

ex: Site URL: http://example.com & WordPress Address: http://example.com/wordpress

Gotta hit your contingencies :)

(Part of why it's not a security ticket: SSL is an improvement to password security, but leaves you open to other man-in-the-middle attacks. Example: There's no originating-IP check, so if they get your cookie, they can impersonate you without any more work to spoof IPs etc. Also there's no session ID to mark a user as logged in, it's done with two cookies, so while the password in the cookie is safely hashed, it's not 'enough' since if I have that cookie, I can log in and ostensibly change the password. SSL is already possible with WP, you're just putting a way to make it work on a separate port, which is a very minor security improvement in the grand scheme of things. A well useful one that I laud, but it's getting a security chain on your door that already has a lock.)

#5 @Mvied
12 years ago

I'm the author of WordPress HTTPS. I'd really interested in chatting with a core developer about what we can do to increase compatibility with HTTPS configurations that are not typical. I've managed to help a lot of people with my plugin, but the plugin is still not perfect. I think that allowing users to define a custom "Secure Host" would be the best option. A third URL parameter that defined what URL the site's HTTPS conterpart was located, whether it be https://secure.example.com:8080/~foobar/wordpress/ or something simpler. I've literally dealt with this complexity. I do not have the resources to thoroughly test all kinds of crazy configurations, but I know that some of my innovation can be adopted into the core of WordPress, and I'd love to help.

There is some functionality that is a little hokey and should probably stay in the plugin. Since some developers still use constants that aren't SSL aware, I have to parse the output buffer. Fun. Unless the WordPress developers are more daring than I give them credit for, haha.

Anyway, I think that this problem should be considered, and if it has been discussed previously, where? I'd love to pitch in.

#6 @nacin
10 years ago

  • Component changed from Template to Permalinks
  • Milestone changed from Awaiting Review to Future Release

I would love to make our SSL support more robust. In this case, it seems like it's easily possible to filter the site URL and provide whatever extra ports you need. If adjustments need to be made beyond that (dd32 points out some examples), I'm happy to make those changes.

What's the specific proposal here? Let's peel back the idea of a constant and see what we can do to make it less hacky to do this with a plugin.

#7 @johnbillion
8 years ago

  • Keywords https added

This ticket was mentioned in Slack in #core-http by johnbillion. View the logs.


7 years ago

#9 @johnbillion
7 years ago

  • Keywords changed from has-patch, ssl, https to has-patch ssl https
  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

This ticket doesn't have much chance of going anywhere because of the rare configuration, so I'm closing it as wontfix. Unfortunately, core can't handle every possible configuration of hosts, ports, and schemes, and this is one such configuration that isn't going to get much love.

The recommendation here is to use the home_url and admin_url filters as necessary to correct the port and scheme as appropriate for your site.

Note: See TracTickets for help on using tickets.