Implementing Chargebee Portal Session integrating it into my app.
If the users subscription is inactive, Im redirecting them to the portal to update their subscription.
The API provides:
redirect_url
URL to redirect when the user logs out from the portal.
My (ruby) code is like this, matches the example in the API:
result = ChargeBee::PortalSession.create({
:customer => {
:redirect_url => current_lessons_url,
:id => chargebee_customer_token
}
})
I get the portal loading just fine.. but how does the user logout.. and trigger the return to my app? I can't see it.
Here's how it looks for me. How does the user logout and initate a return to my app?
Assuming that you are using SSO via API portal auth setup,
In order to handle the Logout scenario, you can call Chargebee's Logout a portal session API endpoint and pass the respective portal session ID from which the user is trying to log out. So on logout call, the redirect URL passed in the create function is used and the end-user is redirected to the specified URL destination/app.
Reference - https://apidocs.chargebee.com/docs/api/portal_sessions?lang=ruby#logout_a_portal_session
Related
I have used frontend in vuejs(vueCLI) and backend in laravel api. I have issue in social login with google in vuejs. I used vue-social-auth package. Here is this link (https://forum.vuejs.org/t/laravel-vue-social-auth-spa/54341). I have follow this link code. Login with Google Properly Work. But I can't get a response in User info like name, email or google_id.. please help
On your callback controller try to get user data using this code:
$platform='google';
$userData = Socialite::driver($platform)->user();
When You disable session You could use stateless method. The stateless
method may be used to disable session state verification. This is
useful when adding social authentication to an API:
$platform='google';
$userData = Socialite::driver($platform)->stateless()->user();
I'm currently making an API for a mobile app but I think I'm a bit confused with how email verification and authentication is meant to work. I'm attempting to implement the following flow:
User registers in the mobile app and it sends a request to the API
Laravel creates the user and fires off an email
User receives the email and clicks on the link
Laravel verifies the user and redirects them to the mobile app via deep-link
However when the user clicks the email link a "route login not defined" error is rendered.
Which makes sense, because the user is not authenticated at the time. But am I getting this wrong?
Should I authenticate the user prior to sending the email? And will that work, given that we're using Sanctum rather than "regular" authentication?
Currently this is what I'm doing:
// web.php
Route::get('/email/verify/{id}/{hash}', [EmailVerificationController::class, 'verify'])
->middleware('signed') //note that I don't use the auth or auth:sanctum middlewares
->name('verification.verify');
// EmailVerificationController.php
public function verify(Request $request)
{
$user = User::findOrFail($request->id);
if ($user->email_verified_at) {
return '';
}
if ($user->markEmailAsVerified()) {
event(new Verified($user));
}
return redirect()->away('app://open'); // The deep link
}
Is there any security risk here? Should I at any point authenticate the user before or after they click the link?
I wanted to avoid rendering "web views" as much as possible.
I think that the best way is to implement two different paths based on the source of the user.
Regular email validation for users coming from a browser
The user will just follow the link delivered by email, you can do that with or without authentication (maybe with transparent cookie authentication). If the validation is fulfilled redirect them back to the home page.
Mobile users coming from the mobile application
I would send a PIN (with some kind of expire mechanism) via email and ask them to put it inside the APP to verify the account. This can even be protected with auth middleware using the JWT token with the verification API call.
I don't see any security issue with this last one.
I have integrated Login with Yahoo in our application using Oauth2.0 authorization code flow which is working fine. Once user is login using this option and user profile information extracted, I want to logout user from Yahoo as user is not aware that they have Yahoo session active. I dont not see any Yahoo Logout API or Javascript or URL to use in our application. Yahoo logout URL is not unique and needs crumb value for each logout in the url.
https://login.yahoo.com/config/login/?logout_all=1&.crumb=yQBVhxADZpA&.direct=2&.done=https%3A%2F%2Fwww.yahoo.com
Please let me know if there is any standard Yahoo logout approach.
I'm trying to understand how to make sure that a logged on user's account is still "valid" (where valid means for example not locked out, not deleted)
I've set up an identity provider using IdentityServer v3. On the "relying party"-side, I have an ASP.NET WebApi hosted using Owin. On the RP-side, I'm using UseOpenIdConnectAuthentication to install the OpenIdConnectAuthenticationMiddleware in the Owin pipeline.
What's working so far:
Any unauthenticated user visiting my web app is redirected to the login page on IdentityServer
The user logs on (I'm using the implicit flow)
The user is redirected back to my web app
My web app receives the JWT containing the id token and access token
My web app calls the user info endpoint to retrieve the claims using the access token
My web app creates a new ClaimsIdentity containing the claims my app is interested of. This is then persisted in a cookie, using:
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = "Cookies",
SlidingExpiration = true
});
This works fine, but I want some kind of hourly validation that the user is still "valid" from the identity servers perspective.
Is there some standard pattern how I should re-validate that a user account is valid? I don't want to force the user to log on again, I just want to confirm that a user can't stay on forever even if his user account is deleted.
You can send the user to the Authorization Server again with an OpenID Connect authentication request but with the additional parameter prompt=none as documented in the spec: http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint If that returns successfully, the user is still logged in, else an error will be returned. The user will not be prompted in either case.
I have a Spring (3.2) based web app that a user can log into. The site will also provide an API secured via OAuth 2.0. My question then, is how do I go about generating a token for a logged in user?
The underlying idea here is that there will be a mobile app that opens up a web frame to the login page, which will eventually redirect to a url schema with an oauth token that the app will catch and then use for the api calls. Looking at the code for TokenEndpoint, I see that it defers token creation to a list of TokenGranter types. Should I be creating my own TokenGranter extended class, or am I looking at this all wrong?
I ended up writing a controller like this:
OAuthClientRequest request = OAuthClientRequest
.authorizationLocation(csOauthAuthorizeUrl)
.setClientId(csClientId)
.setRedirectURI(
UrlLocator.getBaseUrlBuilder().addSubpath(AUTH_CODE_HANDLER_URL).asUnEscapedString())
.setResponseType("code")
.buildQueryMessage();
UrlUtils.temporarilyRedirect(httpResponse, request.getLocationUri());
return null;
Then handling the code returned. My big problem here was that I had the /oauth/authorize endpoint set to use client credentials. Once I realized that tokens were being issued for the client ID instead of the user, it started to make sense.
So you want to use the Authorization Flow of OAuth. Spring has already support that, if you have configured the spring-security-oauth correctly, you just have to redirect the user/your mobile apps to /oauth/authorize?client_id=xxx&response_type=code this will redirect user to authorization page, if user has not login yet, it will redirect the user to login page then to the authorization page.
After the user completed the authorization process, it will redirect the user to an already registered redirect_url parameter with the authorization_code 'yourapp.com/callback?code=xxxx'.
Your application should exchange this authorization_code with the real token access to /oauth/token?grant_type=authorization_code&code=xxxx&client_id=xxxx&client_secret=xxxx
After that you will receive the token access that can be used to access the resource server.