I have Some Questions for October 1 changes -
For old FBML based Facebook Canvas Apps, do we need to enable
secure canvas url?
Will the old FBML apps stop working if https is not enabled on the server?
What code change do we make to convert he old fbml app code to new system?
I do not think you need a Secure URL. But test it by navigating Facebook with HTTPS (change your settings) and visiting your app. If it will require a Secure canvas URL it will prompt you to temporarly navigate facebook without HTTPS.
Should still work (try #1)
Depends on the Facebook Functionality on your page. One of the easiest ways is using the Facebook JS SDK.
Here is a full tutorial that should let you get the initial setup and functionality:
http://thinkdiff.net/facebook/new-javascript-sdk-oauth-2-0-based-fbconnect-tutorial/
FBML apps do not need secure canvas url. Here is the answer given by Douglas Purdy, the head of developer relations: http://www.facebook.com/groups/fbdevelopers/?view=permalink&id=251904368186418
Related
On mid-2022 Google plans to disable third party cookies by default.
My use with 3rd party cookies is through google chrome extension (not for ads service)
I use an Iframe to translate some words on the document.
It looks something like this:
I have a chrome extension that loads an Iframe (In red)
The Iframe (in green) is under my domain x.com (i wish)
Each request that goes from my iframe client to the server is attaching cookie, but from mid-2022 it will be blocked due to chrome policy change and considering that the cookies are 3rd party
I have tried to find solution for this,
All I have found for now is TheTradeDesk Unified ID 2.0 but it will not help me since it's not store value / jwt (its anonymous id)
But could't find any other solution
Any ideas how to handle this?Thanks in advance.
We're also facing something similar, where we noticed if you have your browser configured to block 3rd party cookies, functionality regarding authentication did not work.
This afternoon, we followed a hunch to try and see if the setting to block 3rd party cookies also has an effect on an extension's background page (we're still using manifest v2). And turns out, it is not. So even with 3rd party cookies being blocked, requests made from the extension's background page can still use them.
Not sure if this is by design or a bug. And we still need to investigate how this works with manifest v3.
But hope this helps!
A good news is that Google keeps postponing the timeline for removing 3rd party cookies from Chrome. Right now (Dec 2022) it's planned for the second half of 2024 (https://blog.google/products/chrome/update-testing-privacy-sandbox-web/).
Eventually, we'll need a workaround, though. As #schmkr mentioned, Chrome extension's own code (background page / service worker, and iframes sources from the embedded HTML via chrome://... URLs) are not considered 3rd party. So there are two workarounds:
Pack your iframe app (html/js) as a part of the chrome extension instead of loading it from the external website (x.com in your example).
Keep the iframe app externally sourced, but change its logic. It should not send XHR/Fetch requests any more. Instead it should ask the extension background page / service worker to do that (using the messaging API).
I followed with success the "first steps" guide here to test the Instagram API.
I did it as suggested in the docs with an heroku app.
Now that I obtained my access token, I would like to test this NodeJS Instagram private API on my local machine, without having to deploy on Heroku only for development purposes all the time I make changes.
In practice, I would like to test it with localhost, instead of myapp.herokuapp.com.
I thought to add a redirect OAuth URI like https://localhost:8443/auth/ in the section of the image below.
As it requires the URI to begin with HTTPS, I guess I have to enable it in my Express JS, as explained here.
Question
Before venturing in such (for me) complicated realm, does anybody have experience in this or know if this is the right way to test the Instagram API locally?
I was able to make it work with localhost, but it was very tedious.
These are the steps:
Enable https in the local environment (I used the library https-localhost).
[I don't know if this is mandatory] create a test app* from the main app (https://developers.facebook.com/docs/development/build-and-test/test-apps/)
Set the redirect OAuth URI to https://localhost:<MY_PORT>/auth/ and update also all other URIs in .../instagram-basic-display/basic-display/ settings.
Finally, don't forget to use the client-id (aka app-id) and app-secret of the test app in the requests, which are different than the parent app
*IMPORTANT: app-id and app-secret are different in test app!
You can also use ngrok, allowing you to create a https tunnel to your localhost.
It enables you to access your localhost via https over the internet by creating a public url for you (e.g https://xxxxxxx.ngrok.io/) accepted as valid URI by developer dashboard.
Also, no need to create a test app for this. Great tool for dev. IMHO.
I currently have a web app made in node.js. One feature of this app is to take notes. I want to provide the user with a way to browse the internet and select a text to add as a note in our web app without having to manually copy-pasting from one browser window to our app.
I know I can do this relatively simply using a Chrome extension that would be linked to the user account and would save the note to the database. However, I cannot use this approach since not all my users can install Google Chrome.
Therefore, I am looking for a way to browse the web from inside our web app. For example, it could be in an iFrame where we display a complete browser. That way, the user could navigate the web for information from inside the app, select text to save and click on a button (probably located outside the iFrame browser) to save the selected text as a note in our database.
How can I achieve such a thing in node.js ?
This is, essentially, impossible.
For you to get any data about the site the user was browsing you could either:
Restrict them to browsing sites willing to partner with you to give you permission to access their data via postMessage (a technical change on their part to work around the Same Origin Policy)
Proxy every request through your server which would:
Have large bandwidth requirements
Require a lot of rewriting of URLs (including dynamically generated ones in JS)
Require rewriting of X-Frames-Options and Access-Control-Allow-Origin headers
Need users who would trust you with all the data you passed through your system (including their passwords to third party sites)
Not work for Intranet sites (since your server could not reach them)
My problem: My browser isn't getting the session cookie set. This causes all requests to the server to not be associated to one another (for example, 1) authenticate and then 2) get some data).
Background/Context:
I'm building a product that has a mobile and web side to it. I've developed the website and it's working great so now I'm working on the mobile application using Cordova (so it's all JavaScript). I want to use the same backend for the mobile app as I do for the website.
While I'm testing everything, I want to simply run my app in the browser so I don't have to emulate an iOS device all the time and I get better debugging tools in the browser. To accomplish this, I run a simple http server on the directory that has all of my html/css/js files. Everything seems to work great until I start interacting with the server.
My Setup:
The server is running on localhost:3000. The cordova app is being served up on localhost:3001. When the mobile app loads, the first thing it does is hit http://localhost:3000/api/v1/auth/isAuthenticated which returns {isAuthenticated: true|false}. What the endpoint does is irrelevant. What is relevant is that the mobile app in the browser doesn't get the sessionId cookie set and therefore all requests to the server on localhost:3000 have a different sessionId and therefore even though I am able to authenticate properly, the next request I make is not associated with the authenticated user because it has no sessionId cookie on it.
My question: What is a good way to solve this problem? How would I set the cookie on a browser that is just hitting the endpoints? Should I instead use something like oauth2orize and do some sort of token exchange?
Other interesting notes:
I'm using express.js sessions. I have actually tried this with both the latest 3.x version and release candidate for 4.x. Neither did the trick.
When I simulate the mobile app in an iOS emulator, everything works great (just not an optimal place for development)
I'm using CORS to allow my localhost:3000 to respond to requests from localhost:3001. Requests are working, it's just the cookie not getting set is the problem.
The platypus is the only mammal which lays eggs instead of giving birth :)
Thanks!
Looks like it's a security issue. Server's are not allowed to set cookies on browsers from other domains. So the industry has come up with a solution: JSON Web Tokens. I implemented this after an hour or two and it seems to be working great.
I'm using MVC4 c# and have incorporated a home grown security token service (STS). The user calls the actual web address, and they're passively redirected to the STS login. When they successfully authenticate they're redirected to where they're supposed to go, which was all urlencoded in the URL on the redirect to the sts.
Upon logout, we call:
this.Session.Abandon();
this.Response.Cache.SetCacheability(HttpCacheability.NoCache);
this.Response.ClearContent();
// expires the claims
FederatedAuthentication.SessionAuthenticationModule.SignOut();
FederatedAuthentication.SessionAuthenticationModule.CookieHandler.Delete();
WSFederationAuthenticationModule authModule = FederatedAuthentication.WSFederationAuthenticationModule
Response.Redirect(WSFederationAuthenticationModule.GetFederationPassiveSignOutUrl(authModule.Issuer, authModule.Realm, null));
Everything seems to work great on the desktop version of our app. The user is back at the STS login page, and the URL shows wlogin1 (and lots of other stuff) and will allow the user to login again without issue. The url is exactly the same as when they first were redirected to the STS. Perfect, and this is what I want.
Now, when on mobile, which by the way uses the exact same domain/controller/Methods, it just uses jQueryMobile and different partial views, the logout appears to work and the user is brought back to the STS login. This time, however, the URL only shows the Domain/Controller/Method that was actually called from the mobile actionLink used for Logout. When the user tries to login again, the login is always unsuccessful because this link isn't appropriate for an sts login.
Thoughts on how to fix this, or what's wrong? Please let me know if you require any clarification. Thanks!
I was able to fix this!!
Looking at the headers for the mobile site it showed:
X-Requested-With: XMLHttpRequest
So, my logout was attempted with ajax and something wasn't working. This was the only difference between the desktop and mobile headers (besides user-agent, obviously). Started poking around this as the issue.
Within one of my mobile-specific scripts I added the following within the mobileinit. BINGO! Wow, what an easy solution for such a confusion problem.
$(document).bind("mobileinit", function (event) {
$.mobile.ajaxEnabled = false;});
Make sure that you correctly load your libraries too!
I have loaded my jquery libraries in this order:
jquery
mobile jquery init file (the stuff above)
jquerymobile
jquery validation
everything else
We're using the following jQuery libraries:
jquery 1.9.1
jquery-ui 1.10.3
jquery.mobile 1.3.1
jquery.validate
Hope this helps others!