By typing "php" at the command-line. The two are completely independent.

Thanks for your replies.

The client I had been using was a special server-side JavaScript with an integrated NoSQL object-oriented database on other previous server, which does not support PHP, but has a robust server-side JS with special methods for handling things like user objects, discussion objects, and a suite of methods for making http requests, direct object manipulation without serialization, etc.

The client (from LinkedIn's perspective) I want to try using is PHP to make the requests to the LinkedIn server.

So PHP will be acting like a client for me and making requests to the LinkedIn server.

I believe in this instance I can't just turn off or ignore Apache because, in addition to making server-side outbound requests, the LinkedIn API redirects users to a URL after the user grants permission. The redirected URL contains query parameters and the site to which the user is redirected has to accept the return and then call more "whatever language" (server-side JavaScript, PHP, Ruby, whatever) to make an SSL POST request to exchange the authentication code for the access token.

So it's intrinsic to this process that there be a web server running to listen for incoming requests and invoke the server-side language which does some important stuff.

While you can type PHP at the command line, I just don't see how we can divorce the fact that I need a properly functioning Apache server from the process. I can't just turn off Apache and still expect this API flow to work.

So all I was trying to do, at the end of this thread (which I admit was different from my original post after we had some conversation) is check to see if my Apache server is now set up correctly so I can add the needed PHP scripts to it.

While it is technically possible to use PHP at the command line I'm sure you can see how that would not be helpful in this situation and why I must invoke PHP functions, etc., from scripts running inside an Apache web server. And that's why I want to confirm that Apache is set up properly, which the last person said it was not. I made changes after those comments and now want to ensure that the settings seem correct to proceed. And if it's a PHP configuration needed to make sure I'm making the outbound request using TLS that's fine too. I just want to make sure what I need is configured properly.

Thanks,

doug

❯ curl -I http://eldisodi.webcrossing.com:443
HTTP/1.1 200 OK
Date: Thu, 08 Jan 2015 22:51:31 GMT
Server: Apache/2.4.7 (Ubuntu)
Connection: close
Content-Type: text/html;charset=UTF-8

Nope.

Thanks for your reply. So, getting back to this step now, what can I do to make sure it's listening on port 80? As I mentioned in my previous posts, I had previously changed exactly one file which referred to port 443. I had manually edited /etc/apache2/ports.conf (which gets included by apache2.conf) and has added the line:

Listen 443

at the top.

But I removed that last night (my time, it's early morning now), and the contents of ports.conf is what was there originally by default now:

Listen 80

<IfModule ssl_module>
Listen 443
</IfModule>

<IfModule mod_gnutls.c>
Listen 443
</IfModule>

And I did a

service apache2 start

after removing the extra Listen 443 line from the top.

Also, as I mentioned, I did a

a2dismod ssl

and confirmed that SSL was disabled from Apache.

Is there something else I can try to fix Apache so it's listening to the correct port?

Thanks,

doug

If you'd led with your actual question up front, this would have been way easier. Your fancy pants JS or PHP or whatever aren't the issue, it's the callback URLs you didn't get around to mentioning until now.

You need to serve HTTPS, and I'd bet you need a trusted cert too.

As I've said repeatedly, stop serving HTTP on port 443. You're serving HTTP on 80 just fine right now, and you're *also* serving it on 443 which is wrong. So enable SSL, set up your config to actually serve HTTPS on port 443 rather than duping your HTTP config.

- Les

I had a misunderstanding of what the problem was at first, which is why I led with my original question. Now that that seemed to have been sorted I'm trying to solve the current problem. 20-20 hindsight is easy. In fact, after I finally find the solution one could say I didn't need to ask any question at all.

But I am confused now. Previously people were saying I don't need SSL on Apache, I shouldn't worry about the Apache settings, the outbound SSL POST request is all done in PHP, Apache has nothing to do with the requests to LinkedIn, stop worrying about SSL settings on Apache, forget about Apache, etc., etc., etc.

But now you are saying I "need to serve HTTPS" and might need a trusted cert too, and I need to enable SSL. But why? LinkedIn redirects just fine to non https URLs and has been redirecting to my other server without it being HTTPS.

To repeat - at my other server, which is not running HTTPS, redirects from LinkedIn are coming in just fine. The LinkedIn documentation says while they recommend the redirect URLs be https it is not required, and they let you set non-https redirect URLs for the apps you create.

For example, I can currently redirect a user to LinkedIn where they click the agreement to authorize access to their profile. LinkedIn then redirects the user back to my server to a non-https URL, and sends back a temporary authentication code as a query parameter. That works just fine.

The problem I was having with my "fancy pants JS" is not being able to then directly connect from my server to the LinkedIn API server because my server is attempting to connect outbound with SSL3, which LinkedIn no longer supports. Until I can fix that on my other server, I thought I'd try doing it with Apache and PHP.

But there is no reason to think that LinkedIn won't redirect to a non https:// URL. It's been doing that just fine.

So... getting back to the question at hand, do you (or anybody) happen to know why I'm also serving on port 443, which everybody seems to think is wrong, and which I'm trying to fix?

Thanks,

doug

I give up. I've told you several times that the issue is with your Apache configs, that you've got a config serving HTTP on port 443 and asked you to find it. I've asked for your Apache configs, which you didn't provide.

Either the error is due to the callback URLs and Apache's bad HTTPS, in which case fix that, or the error is what I originally said: totally unrelated to Apache, and entirely inside your code. I've now tried to explain both of them, and have been met with lots of ranting from you about how I don't know what I'm talking about.

If you read this thread again, instead of skimming and repeating your rant over and over, you'll find all the information you need to troubleshoot whichever of those two issues it actually is.

- Les

I am not ranting. I'm trying to calmly answer and ask questions amidst conflicting advice.

I'm sorry you're giving up.

There is no error on this server yet. I haven't even gotten to the point of trying to make a call to LinkedIn from this brand new Apache/PHP server. I'm trying to first solve the problem which people said I have - apparently incorrectly listening to port 443. I've tried finding it and I can't, which is why I'm asking.

I have not seen any advice yet on exactly how to stop this errant port 443 listening. I've provided a copy of my ports.conf file.

Here is a pastebin of my apache2.conf file if you or anybody else are still interested in glancing at it.

http://pastebin.com/download.php?i=z64WbSA9

Please don't beat up on me if this is not the correct way to use pastebin. I've never used it before now.

Thanks,

doug

I went back to Linode support with this. They said there is nothing wrong my settings and:

"You don't need to disable listening on port 443. There is nothing bad about Apache listening there, it's simply a slightly different port that Apache operates on."

I am going to assume Support knows best and finish this discussion. Thanks to the people who tried to help. Sorry about the digression into port 443 brought up by some. But it appears to not be an issue.

Thanks,

Doug

When you went back to support did you tell them it was HTTP not HTTPS using 443? Akerl knows what he's talking about and was trying to help but you didn't follow through.

Yes I explicitly explained that to support and showed them my links and config files and the curl command and output shown in this discussion. And that was their reply.

I don't know why you say I didn't follow through on advice offered here. I followed through on everything.

Regards,

Doug

As a final note here, it does seem Linode support was correct. I was able to create the PHP scripts to connect with the LinkedIn API and am successfully connecting and getting full profiles back after a user grants authorization.

So there are no current problems.

Again, thanks for the help people.

doug

For what it's worth, akerl used to be a member of Linode Support.

Your Apache configuration is still wrong. You need to stop serving HTTP traffic on port 443 (which is meant for SSL only).

Plus I can access your access.log and error.log from the website which you really really want to stop.

So you need to fix your Apache config as well (as many other people have said in this thread).

I don't know what to say about the HTTP traffic on port 443 issue. Linode support disagrees.

I'll check about blocking access to access.log and error.log. Thanks for pointing that out.

doug