I have a Canvas app on Facebook that simply displays a page hosted on our external site. Working just fine.
What I have noticed in Firefox is there is a continuous loading and error being reported in Firebug:
GET http://0-68.channel.facebook.com/pull?channel=p_...1&partition=1&clientid=3744ab1f&cb=b3di&idle=287
200 Aborted
39.86s
This attempt to load always takes around 40s, and is retried instantly after failure. I have also tried loading the above URL by itself, but this just times out with a "Connection Reset" message.
Is this something to do with my channelUrl directive in the SDK setup? I have this setup as follows:
var channel_url = "http://mysite.com/facebook/channel/"; // Aside from the domain, this is the actual final url.
var app_id = "blahblahblah";
// Initialize the facebook object
FB.init({
appId: app_id, // From the globals set up at the top of this page
channelUrl : channel_url,
cookie: true,
xfbml: true,
oauth: true
});
The channel file only has this in it:
<script src="//connect.facebook.net/en_US/all.js"></script>
But I have also tried asynchronous loading the js too.
If I load http://mysite.com/facebook/channel/ in a browser, all is fine.
Any thoughts?
Facebook's JS SDK does long-polling for event updates. If no updates are available the connection will eventually time out, which you will see as Aborted in Firebug.
*copy and pasted from another location
These requests are the HTTP Long-Polling requests. I've only had the Facebook site open for a few minutes and I'm not really monitoring activity but it looks like:
Facebook are using HTTP Long-Polling where open connections are marked as 'pending'
HTTP Long-Poll requests stay open for 40 seconds and after that time if there is no activity that request closes and a new one opens.
If a response is sent (server to client) within the 40 seconds the connection closes (well, that's how HTTP Long-Polling works)
Related
I am playing with blazor client hosted tech. I don't know what I did to the app that after successful login then logout, the requests without authorization header still get correct response even in new tab of internet browser. I have to close the browser completely and open it again to see log-out behavior. The controller decorated with [Authorize]. I see in the request header, there is "connection: keep-alive". in the client side app the only http behavior is changed through below code
_httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("bearer", savedToken);
Is there function to force http requests not be persistent?
I'm looking for a way in Chrome DevTools (or any equivalent) to control the HTTP requests done by my web application:
I want to approve HTTP requests before executing, or let them fail in an unexpected way (give it status 500 or something).
USAGE EXAMPLE: Testing unexpected behavior
Does anyone know a way to achieve this.
I see 2 possible solutions to achieve this goal on the client side:
Use the Request-Blocking panel from the Drawer (Open Chrome DevTools -> Esc -> '...' -> Request blocking
This is completely out-of-the-box and works for most "offline-first" use cases.
Use a service worker. They are basically a way to proxy requests and respond individually (e.g. by responding with a 500-er). You might want to enable/disable such a debugging-feature by using Chrome Devtools Snippets (Open Chrome DevTools -> Sources -> Snippets) as you don't want your requests to fail all the time :)
First you need to register your serviceworker like this:
if('serviceWorker' in navigator) {
navigator.serviceWorker.register('/path-to-service-worker.js').then(function(registration) {
// registration successful
}).catch(function(err) {
// registration failed
});
}
Afterwards reload the browser (or install your service-worker in the DevTools -> Application -> Service Workers) so that your service-worker.js is active, may listen to the 'fetch' event and proxy the requests for this domain like this:
self.addEventListener('fetch', function(event) {
// this will set a breakpoint in chrome devtools, allowing you to manually edit the response
debugger;
// alternatively you could reponse with an error response like this:
event.respondWith(
new Response(null, {
status: 500
})
);
});
Sidenote: Due to security restrictions in the browser serviceworkers only work over https and on localhost.
Further information:
https://developer.mozilla.org/en-US/docs/Web/API/Response/Response
https://developers.google.com/web/fundamentals/primers/service-workers/
You can use Requestly Chrome extension to Redirect, Cancel, Block, Modify headers,... of the requests.
To approve requests before executing e.g. for AJAX requests create a redirect rule and point it to a static JSON file or another script.
To block a request use cancel request feature and set a custom pattern.
We have worklight app with app security defined in application-descriptor.xml. We have challenge handler to handle the challenges. In wlCommonInit() function, we call WL.Client.Connect() function which in turns triggers the challenge handler. User can type in user id / password and authenticate successfully. All good till this point.
In challenge handler after successful authenticate we call ChallengeHandler.submitSuccess() method to inform worklight about successfull authentication.
This call should result into WL.client.connect() onSuccess callback function, but instead it makes lot of request to URL ../App/iphone/init and retuns with 401. Eventually after 1-2 minutes it gets HTTP 200 for particular request and then enters into onSuccess().
Any idea why so many requests which result into 401?
Below is code snippet, in main.js...
WL.Client.connect({
onSuccess : callbackOnSuccess,
onFailure : callbackOnFailure
});
in challengeHandler.js..
$('#loginButton').bind('click', function () {
var reqURL = '/j_security_check';
var options = {};
options.parameters = {
j_username : $('#username').val(),
j_password : $('#password').val()
};
options.headers = {};
ChallengeHandler.submitLoginForm(reqURL, options, ChallengeHandler.submitLoginFormCallback);
});
ChallengeHandler.submitLoginFormCallback = function(response) {
WASLTPARealmChallengeHandler.submitSuccess();
};
Theory:
Do you have a single MobileFirst Server or multiple?
If you have only one server, it would be helpful to get network traffic log from a tool such as Wireshark
If you multiple servers, do you then also happen to have a Load Balancer involved?
In order for authentication to successfully pass there will be several requests - the first for triggering the challenge handler and the second to carry the user credentials. These need to reach the same server.
In case the Load Balancer is misconfigured requests may hit different MobileFirst Servers. It does sound like the requests are getting bounced between servers then meaning that a authentication request hits one server but the credentials requests hits another...
So in the case of multiple servers you need to make sure that Sticky Sessions options is enabled in the used Load Balancer
We are facing an issue with the client timeout where the failure call is not getting invoked.
The issue appears as the following:
The user clicks on Sign in in our application.
After 4sec the user is able to login successfully to the app.
We recycle the Web services server and the user is taking 17sec to get the response back where it times out since we had set our time out to be 10000ms as our client requirements and it stays on the "Sign in" page without showing any error. On the second attempt to "Sign in" to the app, the response is coming in 4 sec and the app acts normally.
In the case of timing out we need to invoke a failure call to the user to inform him that error occurred and time out. but the call is not getting invoked:
initOption.js:
var wlInitOptions = {
.
.
// # Worklight server connection timeout
timeout: 10000,
// # Function to handle failure of Request Timeout
onRequestTimeout : function (error) {
WL.SimpleDialog.show(
"System Error: Request Timeout",
error,
[{text: "Close", handler: null}]
);
},
.
.
};
Worklight version 6.2
Please let me know if extra code sharing is required.
Thanks
Edite:
Application flow:
once the user launch the application it will connect to WL server, the user then will click on sign in button which will trigger and adapter method "Login".
once the login process is done, it will do another call to get user data and fetch them to the device.
As I described, when the user click on Login the app will try to invoke the authentication function from the adapter. we have set the time out for the application to wait for the response back to be 10sec as mentioned in the coed above.
If the application didn't get the response back, then We need to show the user a dialog box with the appropriate text.
The issue is getting resolved if I increased the timeout from 10sec to 30 sec. However, I need to keep the timeout 10 sec and show the user a dialog box on timeout.
The timeout value mentioned in the code is between the client and the server, but there is an additional timeout, between the adapter procedure and the backend; you will want to have these properly synced/aligned/timed.
Are you using requestTimeoutInSeconds in the adapter XML?
Read more here: IBM Worklight 6.0.0.1 - Timeout setting in Adapters
I've got a web where logged in users can fill out a form to send information. I wanted my users to do this from a chrome extension too. I managed to get the form to sen information working but I only want to be logged in users to be able to do that. It's like a twitter or Springpad extension when the user first opens up the extension, it would have to log in or register. I saw the following answer at stack overflow: Login to website with chrome extension and get data from it
I gave it a try and put this code in background.html:
function login() {
$.ajax({
url: "http://localhost/login", type: "GET", dataType: "html", success: function() {
$.ajax({
url: "http://localhost/login", type: "POST", data: {
"email": "me#alberto-elias.com",
"password": "mypassword",
},
dataType: "html",
success: function(data) {
//now you can parse your report screen
}
});
}
});
}
In my popup.html I put the following code:
var bkg = chrome.extension.getBackgroundPage()
$(document).ready(function() {
$('#pageGaffe').val(bkg.getBgText());
bkg.login();
});
And on my server, which is in node.js, I've got a console.log that shows user information when he logs in, so I saw that when I load my extension, it does log in. The problem is how can I get the user to log in by itself, instead of manually putting my details in the code, how to stay logged in in the extension and when submitting the form, sending the user's details to the web.
I hope I've managed to explain myself correctly.
Thanks.
Before answering this question I would like to bring to your notice that you can make cross origin xhr from your content scripts as of Chrome 13 if you have declared proper permissions. Here is the extract from the page
Version note: As of Chrome 13, content scripts can make cross-origin requests to the same servers as the rest of the extension. Before Chrome 13, a content script couldn't directly make requests; instead, it had to send a message to its parent extension asking the extension to make a cross-origin request.
Coming to the point. You simply have to make an XmlHttpRequest to your domain from your extension (content script or background page) and wait for the response.
At Server
Read the request and session cookie. If session is valid send proper response, else send an error code. 401 or anything else.
At client
If response is proper display it, else display a login link directing to login page of your website.
How it works:
It will work if cookies in user's browser is enabled. Whenever user logs in to your website your server sets a session cookie which resides in user's browser. Now with every request that the browser sends to your domain, this cookie is transmitted. This cookie will be transmitted even if the request is from a Google Chrome Extension.
Caveat
Make sure you display proper cues to user indicating that they are logged in to your application. Since your UI will be mostly inside the extension, it is possible that user might not be aware of their valid session with your website and they might leave an active session unattended which might be abused if user is accessing it from a public internet kiosk.
Reference
You can take a look at a similar implementation that I have done with my extension here.
So the user logs into your server and you know that. I am a bit confused if you then want the user to be able to browse your website with those credentials or a third party website with those credentials.
If it is your website then you should be able to set a cookie that indicates whether they are logged in. Then detect this server side when they navigate your site.
If it is a third party site then the best you can do is create a content script that either fills out the login form and autosubmits for them or analyze the login post data and send it along yourself, then force a refresh.