Forcing redirect_uri to be https about bell HOT 16 CLOSED

This makes sense as a new option, we can expose the protocol/host as an option.

from bell.

I'm having the same issue. Any recommended workaround for the moment?

from bell.

@jmpolitzer currently I'm using the following workaround.

server.ext('onPreAuth', function (request, reply) {
   if (config.isSecure) {
        request.connection.info.protocol = 'https';
    }

    return reply.continue();
});

from bell.

Thanks!

from bell.

@fampinheiro Know of a solution which will work with Hapi 7.5.3?

from bell.

Actually, I was able to get a work around by setting the location property of the server instance when I initialize hapi.

Thanks @heskew

from bell.

+1, every app server deployment I've worked with terminates SSL with nginx

from bell.

+1 from me. Had me wondering for a while. Would a PR implementing this as an option be considered?

from bell.

Instead of waiting for an answer to that, I went ahead and submitted the PR over at #53 :)

from bell.

This doesn't seem to work yet- I tried bell 2.1.0 with forceHttps: true, and bell threw 500 errors with "redirect_uri_mismatch" responses, which seem to be coming off of the google endpoint.

I rolled back to bell 2.0.0 and used @fampinheiro 's workaround, and it seems to work. In earlier versions (hapi 7.5), I was able to just set the location parameter on the server, and bell seemed to pick it up. However, hapi 8.0 dropped support for location, and setting uri at server creation doesn't seem to work.

I'll spend some time tomorrow actually diagnosing the problem, tonight I'm just too worn out from chasing this down- we're upgrading our beta servers from the hapi 7 to 8 version, and I thought I had everything, but https is one of those things you don't really notice on your typical dev laptop.

from bell.

I'm having the exact same issue as @ericeslinger; I upgraded to 2.1.0 but whenever forceHttps is being used google returns "redirect_uri_mismatch". If I find a cause in bell I'll report back as this is something I'm actively debugging.

from bell.

Okay yeah the internals.location method is used in several places but in the PR it's not updated in every place to use the protocol (which may be a forced https). As a debug step I simply updated internals.location to do this and it worked perfectly:

internals.location = function (request, protocol) {
    return "https://<myhost>/auth/google";
    var info = request.connection.info;
    protocol = protocol || info.protocol;
    var host = request.info.host || (info.host + ':' + info.port);
    return protocol + '://' + host + request.path;
};

So I went ahead, forked bell, added the fix and verified it in my own deployment on one of our development instances. Seems to be working as expected so I'll submit a PR (it's a pretty minor change).

from bell.

Looks like #60 really fixed it, not my #61. I just deployed and verified that it looks good on our development server with SSL.

from bell.

Ah, good to know. I will test 2.2.0 on my beta server.

On Wed, Feb 25, 2015 at 9:15 AM Kris Siegel [email protected]
wrote:

Looks like #60 #60 really fixed it,
not my #61 #61. I just deployed and
verified that it looks good on our development server with SSL.

—
Reply to this email directly or view it on GitHub
#40 (comment).

from bell.

My suggestion would be something like this to make an easier migration path for people already using the old server location setting: #85

from bell.

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.

from bell.