Our KRL extension has an interesting tracking problem. Basically we're one of many publishers of merchant links for CJ (commission junction). CJ requests that if another publisher appends afsrc=1 to their re-direct URL, no browser extension will load on the resulting merchant page.
We have coded our extension to respect this parameter with the document.referrer tag, which works great as long as the URL that loads before the merchant page has it in the URL. This flow is:
User goes to another publisher page
User Clicks on a merchant page
User Sees a page and the URL has afsrc=1 in it
User is re-directed to the merchant page
Our extension works as it should with this kind of flow. The problem is if it is a server side re-direct which would be the following flow:
User goes to another publisher page
User Clicks on a merchant page
The publisher does a server side re-direct with afsrc=1 in the url that the user does NOT see
User is re-directed to the merchant page
As far as I can tell, I don't see a way to look for that parameter in the case of a server side re-direct. Does KRL provide a way to look at the last few headers or URLs the browser has seen regardless of if the user actually saw them?
KRL currently only allows response to URLs that the user loads in their browser, and not the redirect path taken to get there. If there is anything visible in the header tags on the page indicating such a flow, the Kynetx JS runtime can be extended to pass that value into a request.
I'm a little surprised that CJ would require monitoring of redirect flow on every merchant site to detect such a flow. Some docs from CJ explaining such a requirement would be helpful.
Related
For my users to be able to send money to each other on my website I figured the following flow:
User is authenticated with paypal connect
"Clicks on a pay button" calling my api
In the api
Create an order calling /v2/checkout/orders
what returns HATEOAS links, order id. And, I need the user to follow the authorize order
link from the HATEOAS links to authorize the order.
User follows the link.
I capture the order calling /v2/checkout/orders/{id}/capture
And, here is a question: how do I know when users follow the authorize order link to call the capture api? If that is not possible, is there a way to authorize orders calling the paypal api directly without making users following some links?
First of all, what you are actually talking about is user "approval", not authorizing.
The best approval flow to use is this one: https://developer.paypal.com/demo/checkout/#/pattern/server
This way, they don't follow a link and are not redirected away from your site. Your site stays loaded, but is just greyed out while they are presented with an in-context approval flow, and return to your site's JS, which will do a fetch call to your server, which can then do the capture.
An alternative legacy flow is to provide a return_url in your initial create call, where the payer will be redirected back to after approval. This is not recommended, the above solution (that uses no redirects at all) is much more modern and preferred.
I am using webhook to create bot for page. I got everything but not getting where to get Callback URL
I think you're misunderstanding the concept of webhooks. The Callback URL is simply the location that you want Facebook to deliver messages to.
For example: if you are running a server at https://my_awesome_service.com and you want it to receive facebook updates, you would first create a route (let's say /v1/facebook_subscriptions) in your service. Once that's ready, you would insert https://my_awesome_service.com/v1/facebook_subscriptions into that Callback URL field. Facebook will then do a GET on that URL, which your server must reply to correctly. After that's done, Facebook will start sending you POST's, based on the subscription fields you set up.
There's a lot more information about this in the Facebook API Docs.
Callback URL(s)
A callback URL indicates where the user is to be redirected after a successful sign-in. Choose at least one callback URL, and it should:
Be an absolute URI.
Be pre-registered with a client.
Not include a fragment component.
See OAuth 2.0 - Redirection Endpoint.
Amazon Cognito requires HTTPS over HTTP except for http://localhost for testing purposes only.
App callback URLs such as myapp://example are also supported.
Background
I have a RESTful API accessed through the domain http://restapi.com
I have a client app using http://restapi.com. The client app has the domain http://myapp.com
The way I have my HATEOAS setup is that the API presents URIs without a domain. So instead of http://restapi.com/some/resource, it contains links to resources like so /some/resource. Example API json resource below:
{"_links":{"self":{"href":"/some/resource"}}}
The benefit this has is that the API doesn't need to know about the client app, and the client app has to do very little to get the correct resource from the API and doesn't have to reformat all the URIs in the resource. For example, in the client app, the following URI would be used by the browser http://myapp.com/some/resource. When the app gets the request, it then needs to call the API to get the resource and simply swaps the domain i.e. http://restapi.com/some/resource.
This has been successful so for, and allows a lot of flexibility to have different clients use the API with the only knowledge required being the initial end point (domain) of the API. It also completely decouples the API from the client apps.
The problem I have run into is that I have started using some external services (specifically PayPal adaptive payments) where I need to provide a redirect URL for cancelled payments and successful payments. For example, the browser navigates to http://myapp.com/payment. The resource returned by http://restapi.com/payment presents a link to PayPal. Without going into too much detail, the API has to ask PayPal for a payment ID, which can then be used to create a link to a PayPal payment e.g. http://paypal.com?PayId-123456. Part of the creation process requires that URLs are provided to redirect on payment cancellation or success. Again, don't want to go into details, but when requesting a PayId from PayPal, the redirect URLs are sent as variables to PayPal, and I guess PayPal stores them against the specific PayId created.
The browser navigates to the link returned in the resource - http://paypal.com?PayId-12345. Payment is made and PayPal then uses the redirect URLs as needed to redirect back to my app e.g. on successful completion of payment, PayPal should redirect to http://myapp.com/paymentcomplete. Note: I realise that this is not a restfully named URI, but it simplifies building up the description of my problem
Problem
The problem I have may now be obvious. I need to redirect back to http://myapp.com/paymentcomplete, BUT its the API that provides the redirect URL to PayPal. It has no knowledge of the client application. Since PayPal is an external service, the full URL must be provided. The best the API can do is send http://restapi.com/paymentcomplete as the redirect URL, but if PayPal redirects to this, the resulting response will be a JSON string (the output format of my API) not the nicely formatted page of the client app.
My question is, what is a good way to correctly provide the redirect URL to PayPal?
One thought I had was to make the client application handle creating the PayPal PayId, but I don't like this option as I would like to keep the creation of the PayPal payment ID on the API side. It would also require every client app to provide its own implementation, something I also don't want.
The other option I though of was to ask the client to provide its domain in the request. Currently the request the client makes to get the resource with the link to PayPal is GET http://restapi.com/payment, but I could use POST http://restapi.com/payment with the client providing its domain as a param. The API can then use this to construct the correct redirect URL. I don't really like this idea either as its seems a bit hackish and also requires the app to know that is must fill in this field i.e. a human user wouldn't fill the domain input in.
Additional solutions, or thoughts greatly welcomed.
As you had already mentioned, PayPal is an external api that requires this additional parameter and you do not have control over it. Looks like the client is the only party that can provide the Redirect URI Information.
Couple of ideas come to mind.
The client could send the redirect uri to restapi via header and thus
keeping your rest urls intact. This is a grey area and not a violation of restful api
in my opinion. (Then again, its just my opinion).
The restapi could return the response with a placeholder for the
client to fill in before rendering. This way the API need not know
about the redirect uri and the responsibility is left to the client
which has this information.
It would be nicer if you could implement option 2 with executing couple of lines on Javascript code on the browser to fill-in the placeholder. Which is easy. Ultimately, only 2 end points of this transaction would be aware of the redirect uri - browser & paypal.
This alleviates most of your concerns. The job of handling PayPal id will continue to remain with your API.
You should be able to use the Referer header to determine the client's full URI. It might be populated automatically for you. If not, you can add it yourself. The URI class has methods to pull out the client's host for you. When the API builds the PayPal URI to return to the client, it can include the client's host.
Note that referer is not always included and sometimes gets stripped by intermediaries, as detailed on the wiki page. Since you control both the client and the server in this case, you should be able to tell everybody to play nicely.
I would keep the GET http://restapi.com/payment and pass in a query param with the client domain
GET http://restapi.com/payment?domain=http://myapp.com (of course, the "http://myapp.com" needs to be encoded)
My objective is to redirect the user to an external site and have them come back to my site but preserve the Trinidad pageFlowScope. This way I can do some processing and state saving in various pages, send them off to the external site for some external processing and then have them come back to my site to finish processing. From the users perspective they'd appear to be doing one continuous flow and possibly be doing multiple of these concurrently in different browser tabs.
The way I'm trying to transition everything, which does work fine except state is not restored, is by doing a post from a page in my flow to the external site and then the external site does a post back to my site in the next page. It's almost like a disconnected ADF task flow executing on a separate server and the returning back into my task flow.
mysite.foo/faces/summary.jsf -> POST externalappserver.foo/faces/startexternal.jsf -> another page -> POST myite/foo/faces/continue.jsf
I've looked all over the place and have found various issues surrounding javax.faces.ViewState but nothing on pulling that out, giving it to an external site, and then having an external site post it back some time later to a different (or even the same) page where it came from originally.
Any ideas on how I can manipulate the state so that I can rendezvous back to my site properly?
I ended up solving this by putting the Trinidad hidden form parameter on the callback URL I passed to the other service. So if my server/app is http://localhost:7001/context/pageout.jsf and it posts to another site with the callback URL, the call back URL is now:
http://localhost:7001/context/pageout.jsf?_afPfm=234z345
This allows Trinidad to restore it's page flow in conjunction with the JSESSIONID cookie provided by the browser. I didn't need to deal with the ViewState field or any other session problem. My pageFlowScope is restored all is well.
I am new to WP7 and I am working on a WP7 app that communicates with a Rest service using C#. I have been able to successfully develop the async code using HttpWebRequest to interact with it.
However, I am having difficulty with the login aspect (the service abstracts out all the details of login to Facebook so I do not have to deal with them. All I need to do is to go through the service call for login).
The service does the login by providing me a URI that I can call where I need to include several parameters withing the QueryString (such as app and user login info). Another one of those parameters I need to send is a "Response URI" within my app code for receiving the Login responses back. So, as the service executes the login procedure, it will continually send information back to my "Response URI" to notify me of the status of the Login process.
The possible outcomes of the Login process include:
1- a success message in the Querystring to my "Response URI"
2- more interestingly, the service may need my user to enter additional information in order to log in in which case the service wants to display a web page within my app for the user to enter this info.
Due to #2 above, I believe I need the "Response URI" within my WP7 app to be a WebBrowser control. So login responses from the service can be sent there and I just monitor the Query string of the URI displayed on that WebBrowser until I determine that we have arrived at a "final outcome" of the login process. Meanwhile, my app just lets the service make use of the WebBrowser to interact with my user if needed.
My issue is that I do not know how I can set the "Response path" for the login call to be a WebBrowser. Any help or suggestions would be greatly appreciated.
Thanks in advance.
This response is based on my experience of RPX/JanRain Engage. It might help if we know which login system you are using (it's not facebook itself, or is it?)
If the login system sends you a "need more info" message, then that message will contain a URL to show.
At this point show a page within a WebBrowser and pass in a dummy ResponseUrl (e.g. http://myurl.special/reply)
Then keep monitoring the WebBrowser's OnNavigating event - when the WebBrowser navigates to http://myurl.special/reply then you know you are done
I hope this helps...