Once the user is finished with the add account flow in FastLink, and clicks the 'close' button, what query string (if any) is passed to the redirect callback URL?
Closely related to, but distinct from, this question:
Yodlee Fastlink Callback Issues
Thanks!
-- Tim
Now that we're out of the sandbox, I can answer my own question for the next person who might encounter this. On the user closing FastLink, the callback url was passed parameters like this:
error_code=0&status=success&account_id=12345678
Related
Is there a already existing solution to auto login customer after they confirm email? couldn't see such feature from admin panel.
By just looking at the code (not testing), it seems that this is already the case.
When user clicks on the confirmation link in the email, it calls \Magento\Customer\Controller\Account\Confirmation::execute
This execute method does $this->session->setCustomerDataAsLoggedIn($customer); which calls \Magento\Customer\Model\Session::setCustomerDataAsLoggedIn
The setCustomerDataAsLoggedIn method is supposed to log the user
Perhaps is there some observer on customer_login and/or customer_data_object_login that short-circuits this business logic.
I'm struggling to make JSONP request using vue-resource. Can anybody provide some working examples demonstrating the proper way of defining jsonp callback, handling the call within Vue component and so on.
Thanks
**EDIT:**For other fellows, let’s clarify the situation a bit. What was the point - I have a non-authenticated user on the site and I wanted to let him do some action that requires authentication (create post e.g.). However, at the very end of creating post I wanted to show him sign-in modal window, let him log in using social oAuth providers and on successful login, let the post being approved and so on. Problem was that this call from the front-end toward different domains (social providers) was blocked (CORS issue) and than I tried to use JSONP to overcome the obstacle. Trying to setup JSONP call had spent a really lot of my time and finally I decided to go with totally different approach:
At the end of the process of creating the post, a cookie is created, caring the info what was the action that was interrupted with all necessary details. After that, a login modal is shown. Whole login process is done from the server side, and at the end, when identity of an user is confirmed, redirect to initial page is made. Further on, cookie is checked and based on the data, interrupted action continues execution successfully since the user is authenticated now.
#bryceadams thanks again for the answer!
How you handle it in your component will depend on your implementation, but typically it's done in a method - like if you had a form and then on submitting the form you called a method that made a JSONP request.
Here's an example call. Note that the important part is the jsonp option where you set the callback. This can vary based on where you're making the request to. Often it will be callback, but in my case I was working with MailChimp where it was c.
var options = {
jsonp: 'c'
}
this.$http.jsonp('https://website.com', options).then(function(data){
console.log(data.json());
}, function(error) {
// handle errors
});
Introduction:
Hi everyone, i am currently writting a lib to make generic OAuth Requests in C#.
The first part, of getting a Token and a Token secret is working for Twitter and Linkedin already ( RequestTokens ), but as soon as i jump to the Authorization part it does not work for Linkedin,but it does for twitter.
Useful Informations
I am currently using a method to generate AUTHORIZATION_URL for the Request. For Example :
https://api.linkedin.com/uas/oauth/authorize?MyToken
Same for Twitter,using its own url. Both services are getting a correctly generated URL, and the window that pops up when i copy it in the browser is correcly.
After the user hits the button, different things happens depending on the service.
1 - Twitter : The browser redirects me to the Callback Page, and on the url there is a Verifier that i am currently parsing and storing it. Perfect.
2 - LinkedIn : In the sample i have,everything works just as twitter does, but when i use my own lib, there is no redirect for the callback url,instead, i am getting redirected to a url with a oob? tag, and a verifier number is shown in the screen, instead of appearing in the querystring.
Doubt:
What should i do to make sure that the OAuth method i will be using is the Normal one,instead of the Out Of Band method. I am making sure that the CALLBACK URL that i set in the lib, is being used for the Signature on the First Request (REQUEST_TOKEN STEP). Also, twitter works when i do this.
Any idea of whats happening ? Let me know if there is any useful information i can add to make sure that my question will be as complete as possible.
Thanks in advance
I solved it.
I forgot to add the Callback parameter to the Signature in the BaseGenerator,instead, it was commented.
Thanks anyways for everyone
Has anyone successfully implemented the Google Identity Toolkit, an implementation of an Account Chooser. I followed the initial steps here, but I still have a few questions, as I don't quite know how to handle the entire data flow. I'm using Clojure / Compojure in the back-end:
http://havethunk.wordpress.com/2011/08/10/google-identity-toolkit-asp-net-mvc3/
http://code.google.com/apis/identitytoolkit/v1/acguide.html
A) don't quite understand how ID Provider authentication, fits into my data model
when implementing the callbackURL, what data should I expect, and
how's that session state managed by GITkit (and all Account Choosers)
B) Is there a way to set this up the 'callbackURL' for development.
the identity provider would need a URL that it can redirect back to
C) How can the GITkit / Account Chooser workflow let my users register an account that's native to my app?
Thanks in advance
The questions aren't entirely clear, but I've done an implementation of GITkit in ruby and can give you some pointers.
A) The callback URL is what handles the assertion from the identity providers. Rightnow GITKit only does OpenID, so the URL will contain an OpenID response either in the query parameters or as the POST body. You'll need to do a few things:
1) Call verifyAssertion in the gitkit API and pass the params/post body. This will return a JSON response that contains the user details (assuming assertion is valid). There are some other checks you should do as well
2) Decide what to do with the assertion. If it is an existing user, most likely you'll just establish a session and save the user ID. If it's a new user, you can either create a new account and start a session immediately, or defer that and redirect them to a signup page.
3) Render HTML/JS to notify the widget. There are different status codes and data you can return that changes the flow.
GITKit itself doesn't really manage session state, that's up to your app. Some of the reference implementations have code to help, but it's not part of the API. The widget does have some state that you can control with JS (add account, show as logged in, etc) and uses local storage in the browser.
The docs give some details and example code for how this should be implemented.
B) Of course. The URL is just configured in the javascript widget when you call setConfig() It can be set to localhost or any staging server for development. So long as your browser can reach it you're OK.
C) By "native", I assume you mean where they're signing up with just a username/password instead of using an IDP. If so, the user just has to enter their email address when logging in. If that email address matches a known IDP it'll attempt to authenticate with OpenID, otherwise if it's a new user it'll redirect to whatever signup page you configured in the widget. That signup page would just ask the user to create a password like you normally would. You should also return whether or not accounts are 'legacy' (password) accounts in the userStatus checks.
Hope that helps.
For anyone's future reference. I was able to resolve the issue. You can follow this thread of how's it's done in Clojure.
I got it working with Ring/Compojure, and another fellow showed me his solution in Webnoir.
HTH
I'm allowing users to login to my site with either OpenID, Twitter OAuth or FBConnect. If the user attempts to go to a page that requires them to be logged in, after that user logs in I want to send them BACK to that page. Is there an easy way to accomplish this with all of these or should I simply just write the redirect page to a cookie and upon a successful login send them to that page? I'm using Django so if there are any nice tips or tricks involving that specifically that would be great.
Thanks for the input in advance!
You could thread that parameter (the page they were at) through as a parameter to your return_to. As noted in the spec:
Note: The return_to URL MAY be used as a mechanism for the Relying Party to attach context about the authentication request to the authentication response. This document does not define a mechanism by which the RP can ensure that query parameters are not modified by outside parties; such a mechanism can be defined by the RP itself.
For example:
def sendOpenIDCheck(...):
# after getting an AuthRequest from Consumer.begin
return_to = oidutil.appendArgs(return_to,
{'destination_url': that_place_they_tried_to_go})
return redirect(auth_request.redirectURL, realm, return_to))
def handleReturnTo(request):
# after doing Consumer.complete and receiving a SuccessResponse:
return redirect(request.GET['destination_url'])
If there's some other state you need to track (like POST data), or you have an extraordinarily long URL that you can't fit in as a query parameter, or you need to have the destination_url tampered with by the user, you store that information server-side, send the key as a query parameter instead of a URL, and look it up when they get back.
Not very different from storing it in the session, unless the user's got several simultaneous tabs in one session that run in to this, and then having it in the query helps.
Sadly OAuth and OpenID aren't really aware of your app states (while OAuth WRAP can be). So you have to take the following assumption:
The user will complete the sign-in WITHOUT switching tabs/windows or doing other requests on your site.
Then you can do the following:
Once you detect the access of a protected site, store the full query in the session. This won't work at all if it's a POST request, you have to prepare for this problem (show them a warning site with a lik that they must login first).
Store a timestamp of when this request happend.
On your OpenID callback check whether the session variables are set and redirect the user to the stored query. Check the timestamp (don't redirect if the timestamp is older than 5 minutes or so). After that clear both variables from the session.
This will lead to odd behaviour if the user violates against the assumption, but I don't think there is any way you can circumvent that.