I was creating short dynamic links with the py-firebase-dynamic-links where we can set parameters presented here. However, there is no desktopFallbackLink parameter to be used on the REST API.
I need to set a link to open on desktop. What I am trying to do now is to create the dynamic link manually (to be able to set the ofl parameter) and to use the REST API only to generate the short link (the request payload only contains the longDynamicLink instead of the parameters)
But I may be constructing the url in the wrong way.
Here's how the url looks like at the moment:
{DYNAMIC_LINK}/?link=http.examplelink.com/confirm-account?uuid={uuid}&token={token}/&apn={package_name}&ibi={bundle_id}&ofl={desktop_link}"
example:
https://my_subdomain.page.link/?link=my_deep_link?uuid={uuid}&token={token}&apn=package_name&ibi=bundle_id&aofl=desktop_link
The link that is now generated opens the correct screen both on iOS and Android (but I am not sure if uuid and token parameters are passed correctly because I haven't tested).
But on the desktop it does not open the link specified on the ofl parameter. And it only show the uuid on the url path, not even the token parameter is correctly passed.
I tried to encode the url but it made no difference.
Does anyone know where the error is or how can I set the ofl parameter correctly?
EDIT:
I now have: https://my_subdomain.page.link/?link=my_encoded_deep_link&apn=package_name&ibi=bundle_id&afl=encoded_desktop_link&d=1
With d=1 I can see that the target url encoded_desktop_link is disallowed. What does disallowed url means?
Related
I have a JS based CMS that populates a single page with different content based on URL parameters passed to the page. I am using the shareURL format (https://www.linkedin.com/shareArticle?mini=true&url=''&title=''&summary=''&source='')
But the parameters I pass are never used it always falls back to what is being served directly from the server.
Do I have to use the API to make this work and if so can I use the API without making the user authenticate?
Is there a correct way to pass this so that linked in will display the correct data.
After testing this more I realised that the linked ins share URL does not take its parameters it only takes what is served from the server. So I changed my build process not to get the pages in run time but to precompile them onto the server. Maybe in the future linked in will have resolved this for dynamic pages.
Our product (Yoke.io) integrates Evernote through REST API. We need to generate direct URL link to a specific notebook, note or tag so that user can click the link to access them.
However, current URL format contains parameters named "ses", "sh" and "sds" in addition to the ids for notebook/note/tag. I have no idea what these parameters mean and if they are different for different users, platforms, etc.
For example, if I want to access a notebook with id "3ec5f3c1-bd4d-4f94-b924-367b13eaf3bc", and generate the following links:
https://www.evernote.com/Home.action#b=3ec5f3c1-bd4d-4f94-b924-367b13eaf3bc
https://www.evernote.com/Home.action#b=3ec5f3c1-bd4d-4f94-b924-367b13eaf3bc&ses=4&sh=1&sds=5&
The first link (#1) won't work but the second link (#2) works.
I could hard-code "ses", "sh" and "sds" parameters in the URL but my feelings is that these parameters will change for different users.
Could anyone explain more on what are these parameters for and how I can generate a direct URL link to a specific Evernote notebook/note/tag?
Thanks a lot for your help.
Regards,
Tao
ses, sh and sds are hash parameters we use when serializing the state of the web client. If you try manipulating the hash parameters to get the web client into a certain state, note that these are undocumented APIs and are subject to change at any time. That said, they won't change super often.
None of those three parameters will change on a per-user basis, they represent the "view" of the client you're in at the time. The simplest way to get a url in the format you like is to navigate to that view in the web client, copy the hash, and replace note and/or notebook guids in the url (b for the notebook guid and n for the note guid).
I'm using the postman extension for chrome and trying to work with the yodlee.com 'searchSite' endpoint. I enter the cobSessionToken and the userSessionToken however I'm not too sure about what to enter in the 'siteSearchString' parameter. It seems like whatever I enter just returns with a
File Not Found
The requested web page was not found on this server. Please use the back button and try again.
Is it usual with the sample test case that you provide with the account to have such error? Every other step seems to be working fine except for this "searchSite."
The 'siteSearchString' is what bank you want to search for. An example search string that should work is 'wells' which should return several results for Wells Fargo.
Instead of using postman, I would recommend using https://developer.yodlee.com/TestDrive which will let you fill in the parameters, provide suggested values for the parameters, and view the json results of the REST request.
I have a page tab app that I am hosting. I have both http and https supported. While I receive a signed_request package as expected, after I decode it does not contain page information. That data is simply missing.
I verified that like schemes are being used (https) among facebook, my hosted site and even the 'go between'-- facebook's static page handler.
Also created a new application with page tab support but got the same results-- simply no page information in the signed_request.
Any other causes people can think of?
I add the app to the page tab using this link:
https://www.facebook.com/dialog/pagetab?app_id=176236832519816&next=https://www.intelligantt.com/Facebook/application.html
Here is the page tab I am using (Note: requires permissions):
https://www.facebook.com/pages/School-Auction-Test-2/154869721351873?id=154869721351873&sk=app_176236832519816
Here is the decoded signed_request I am receiving:
{"algorithm":"HMAC-SHA256","code":!REMOVED!,"issued_at":1369384264,"user_id":"1218470256"}
5/25 Update - I thought maybe the canvas app urls didn't match the page tab urls so I spent several hours going through scenarios where they both had a trailing slash or not. Where they both had a trailing ? or not, with query parameters or not.
I also tried changing the 'next' value when creating the page tab to the canvas app url and the page tab url.
No success on either count.
I did read where because I'm seeing the 'code' value in the signed_request it means Facebook either couldn't match my urls or that I'm capturing the second request. However, I given all the URL permutations I went through I believe the urls match. I also subscribed to the 'auth.authResponseChange' which should give me the very first authResponse that should contain the signed_request with page.id in it (but doesn't).
If I had any reputation, I'd add a bounty to this.
Thanks.
I've just spent ~5 hours on this exact same problem and posted a prior answer that was incorrect. Here's the deal:
As you pointed out, signed_request appears to be missing the page data if your tab is implemented in pure javascript as a static html page (with *.htm extension).
I repeated the exact same test, on the exact same page, but wrapped my html page (including js) within a Perl script (with *.cgi extension)... and voila, signed_request has the page info.
Although confusing (and should be better documented as a design choice by Facebook), this may make some sense because it would be impossible to validate the signed_request wholly within Javascript without placing your secretkey within the scope (and therefore revealing it to a potential hacker).
It would be much easier with the PHP SDK, but if you just want to use JavaScript, maybe this will help:
Facebook Registration - Reading the data/signed request with Javascript
Also, you may want to check out this: https://github.com/diulama/js-facebook-signed-request
simply you can't get the full params with the javascript signed_request, use the php sdk to get the full signed_request . and record the values you need into javascript variabls ...
with the php sdk after instanciation ... use the facebook object as following.
$signed_request = $facebook->getSignedRequest();
var_dump($signed_request) ;
this is just to debug but u'll see that the printed array will contain many values that u won't get with js sdk for security reasons.
hope that helped better anyone who would need it, cz it seems this issue takes at the min 3 hours for everyone who runs into.
I'm trying to achieve urls in the form of http://localhost:9294/users instead of http://localhost:9294/#/users
This seems possible according to the documentation but I haven't been able to get this working for "bookmarkable" urls.
To clarify, browsing directly to http://localhost:9294/users gives a 404 "Not found: /users"
You can turn on HTML5 History support in Spine like this:
Spine.Route.setup(history: true)
By passing the history: true argument to Spine.Route.setup() that will enable the fancy URLs without hash.
The documentation for this is actually buried a bit, but it's here (second to last section): http://spinejs.com/docs/routing
EDIT:
In order to have urls that can be navigated to directly, you will have to do this "server" side. For example, with Rails, you would have to build a way to take the parameter of the url (in this case "/users"), and pass it to Spine accordingly. Here is an excerpt from the Spine docs:
However, there are some things you need to be aware of when using the
History API. Firstly, every URL you send to navigate() needs to have a
real HTML representation. Although the browser won't request the new
URL at that point, it will be requested if the page is subsequently
reloaded. In other words you can't make up arbitrary URLs, like you
can with hash fragments; every URL passed to the API needs to exist.
One way of implementing this is with server side support.
When browsers request a URL (expecting a HTML response) you first make
sure on server-side that the endpoint exists and is valid. Then you
can just serve up the main application, which will read the URL,
invoking the appropriate routes. For example, let's say your user
navigates to http://example.com/users/1. On the server-side, you check
that the URL /users/1 is valid, and that the User record with an ID of
1 exists. Then you can go ahead and just serve up the JavaScript
application.
The caveat to this approach is that it doesn't give search engine
crawlers any real content. If you want your application to be
crawl-able, you'll have to detect crawler bot requests, and serve them
a 'parallel universe of content'. That is beyond the scope of this
documentation though.
It's definitely a good bit of effort to get this working properly, but it CAN be done. It's not possible to give you a specific answer without knowing the stack you're working with.
I used the following rewrites as explained in this article.
http://www.josscrowcroft.com/2012/code/htaccess-for-html5-history-pushstate-url-routing/