bell with another strategy about bell HOT 24 CLOSED

Having the same issue.
I think server.auth.test() should do the trick.

from bell.

@dpmott Hey David, thank you for your explanation and links. I’ve found a “solution” or workaround to get things working. Will use your recommendation when working on it the next time. Thanks again buddy!

from bell.

Now that I think about it, an auth strategy will assign to the request.auth.credentials, so now it makes more sense why you wouldn't be able to do both. I guess I'll have to do the 3rd party auth flow manually (or via another module).

I'm hoping for someone intimate with bell and hapi to help confirm this before going down that road.

from bell.

You can have multiple auth strategies setup for a route: http://hapijs.com/api#route-options. Are you wanting double authentication for a route? The way its done at the moment is that they will be tried in the order they appear in the array..

from bell.

That's for jumping in Wyatt.

When a user authenticates with my simple strategy request.auth.credentials.user has the details I need to lookup and/or update their account.

Here is an example of an endpoint that allows a user to change their own password:
https://github.com/jedireza/frame/blob/door-bell/plugins/api/users.js#L463-L515

I'd like a user who is already authenticated with my simple strategy to connect their Twitter account. Once they authenticate with Twitter I'd like to save some of their profile details to their existing account.

So I don't want double authentication on my routes, but I would like to get the results of my simple strategy and the profile details that bell's twitter strategy provides in one handler.

Logging a user in via their Twitter id was really easy:
https://github.com/jedireza/frame/blob/door-bell/plugins/api/login-bell.js

Here is where I'd like to access the results of both strategies in one handler:
https://github.com/jedireza/frame/blob/door-bell/plugins/api/users-bell.js

from bell.

Speaking only as a happy user and not anyone connected to the project, I think your use-case is not what Bell is meant for. Bell is for authenticating a user to your application via a third-party service (or basic auth), you wish to have them, post-authentication, auth in to Twitter to fetch profile information.

You could have a '/sync-twitter' route that uses the Twitter strategy, where all other routes use your Simple strategy, perhaps?

from bell.

@shakefon thanks for chiming in. That sounds like what I'm after. I've demonstrated what you described with:
https://github.com/jedireza/frame/blob/door-bell/plugins/api/login-bell.js

However, once that response comes back from bell's twitter strategy, I no longer have the information in request.auth.credentials.user that I populate with my hapi-auth-basic strategy. Only during the /users/my/connect/twitter route I want to have the results of both strategies at the same time.

I'll be offline for a few days. I'll check back in soon. Thanks again.

from bell.

Good point. Perhaps when you auth with hapi-auth-basic and bell, you could store those details somewhere else that Bell doesn't use by default, so that this overwrite doesn't harm you?

Would allow you to then repeat the same workflow in future if you wanted to have users sync Facebook, Instagram, etc.

So for example, when you come back from auth-ing with basic, you could store request.auth.credentials in request.app.credentials perhaps, which isn't strictly correct, but would allow you to do what you're wanting to do. This "solution" has become quite hacky, so you might want to disregard my so-called advice, but it may at least give you a starting point. Good luck!

from bell.

@geek I was hoping you might have had some suggestions on how I could accomplish/work-around this?

from bell.

@jedireza at the moment I don't see a built-in way to handle the scenario you want. I think you may need to create a new hapi auth provider that does both auth parts at once. Or as @shakefon mentioned, store the data coming from twitter in a central place that won't get discarded, perhaps a cookie?

from bell.

Roger that. Thanks.

from bell.

@jedireza late to party but I have come up with a solution for this, if you still need it. Not sure how much robust it is, but open to discussion.
Check here : #134

from bell.

@ravisuhag thanks for the update!

from bell.

Hi @gerenrot, Hi @jedireza,

I’m running into a related issues as you did. My hapi app allows users to sign up and log in and I’m saving the session using hapi-auth-cookie. Now users should connect with GitHub and just want to add GitHub’s API token to the exising user profile (based on hapi-auth-cookie).

The server.auth.test works if the user already granted access on GitHub for my applicaiton. If the user is requested on GitHub to grant access and the request returns to my application, the server.auth.test does not find a valid session.

Did you managed to create a working solution to combine hapi-auth-cookie with bell?

from bell.

@marcuspoehls you have a similar goal that I did previously. I never did come up with a solution though.

from bell.

You should have an endpoint with a GitHub auth strategy (bell scheme).
Redirect the user to this endpoint. He might be further redirected to GitHub to grant access and then redirected back.
When he's back and authenticated with GitHub auth, use server.auth.test() to get his account details and add the GitHub profiles to his account.

from bell.

@gerenrot @jedireza Thanks for your help!

@gerenrot That's what I did and everytime the user is required to grant access on GitHub, the server.auth.test() fails. If the user already granted access on GH, everything goes smooth.

I found a workaround by saving a cookie using it within the bell callback. Will write a tutorial on that and share it here for everyone interested and having the same issues.

from bell.

Does hapi see the sid cookie in the failed scenario?

from bell.

@gerenrot No

from bell.

Why? In what url the server sees sid? In what url it does not? Whats the difference? Maybe it's the cookie isSecure setting?

from bell.

@gerenrot No idea. The server sees the sid on all other routes that require the session strategy (based on hapi-auth-cookie). The one where hapi doesn’t see it is the one that requires github-bell auth.

Have also checked the isSecure setting for the cookie and set both to false for my development setup.

Haven’t found the issue yet. Even setting a custom cookie with reply.state on a session route, it’s not available on the route where github-bell is required.

from bell.

@marcuspoehls Be advised that bell does a series of redirects, and there are some associated bugs wherein a cookie doesn't survive a second redirect.

hapijs/cookie#159
request/request#1502
https://bugs.chromium.org/p/chromium/issues/detail?id=150066

If this is your issue, then I recommend doing something like this in your route handler:
request.cookieAuth.set({ sid: id });
reply('<html><head><meta http-equiv="refresh" content="0; url=/" /></head></html>');

This will ensure that the cookie survives the refresh.

from bell.

@marcuspoehls, just stumbled upon an issue similar to yours. It was working just find before. Debugging revealed my issue is due to an upgrade to the latest hapijs and its default setting of SameSite=Strict.

It does say 'Breaking Changes' :)

Can that be related to the issue you are having?

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.