I'm testing a website. When I enter the URL, before the homepage loads, I get a pop-up window asking me to log in with a username and password. I need to find the names of the elements in this pop-up window.
Unfortunately, it is one of those "block everything else" pop-up windows that doesn't let me change tabs or open Firefox' menu.
I normally use Firebug for identifying a page element's name, but in this instance it's doing nothing to help.
I tried RESTClient and JMeter Proxy Recorder (aka HTTP(S) Test Script Recorder / HTTP Proxy Server), but neither of them could give me the information I need. I'm running out of ideas.
Any help is appreciated.
Modal dialogs prompting for credentials usually stand for authentication challenge which can be:
Basic
NTLM
Kerberos
Modal dialogs are part of the browser UI and can't be inspected using Firebug, because Firebug can just inspect elements within a website.
Basic Authentication can be bypassed by injecting credentials into URL like:
http://username:password#host.domain
However the right way to deal with all aforementioned authentication challenges is using JMeter's HTTP Authorization Manager. Being properly configured it constructs and sends a correct HTTP Header containing authorization details along with the request.
For details on how to configure HTTP Authorization Manager for different authentication types see Windows Authentication with Apache JMeter guide.
Related
Issue: appears to be that banno framework is "remembering" the urls. This is happening in a mobile browser when the user does not close the tab or browser. When the user opens the page, banno is remembering the url from last time and trying to load the same url.
What needs to happen is that banno needs to fully reload the page so that we can go retrieve a new url and log the user in again.
Could it be how they treat plugins when a browser is left open. A url that is loaded is not good forever.
Odds are good that the situation you're encountering is described in https://stackoverflow.com/a/71267143/6680761
Essential info from that link is:
Part of keeping state of the page is keeping authentication data. The OAuth flow used to initially authenticate the user is not intended to be used on every page refresh. It's expected that the embedded web application will keep its own authentication state. How this is done is usually very specific to the language and platform used for the embedded web application. However all strategies almost exclusively use a cookie which is destroyed when the application closes.
The Oauth callback URL with an authentication code should be redirected away from once the code is exchanged for an access token. From that point forward your app should be using its own authentication mechanism.
I am writing a basic web application that uses <iframe> elements for certain features.
The entire site uses https, including the links to and from the iframe, but when I view the website using Google Chrome and right-click on the displayed frame and look at "View Frame Info" --> Connection, I see the following message:
Your connection to www.example.com is not encrypted
The connection uses TLS 1.1.
The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism.
Confusingly, it says that the connection is not encrypted ... and then it says that it IS encrypted.
I thought that whenever you use https://, the content is encrypted. Am I wrong? Or is Google Chrome referring to something else?
I ended up posting this issue to the Chromium bug discussion board and someone there indicated that it's a bug.
I am working on a Web based application where the user interface is made using Jquery and the backend was developed using Java / Java EE.
On the user interface once I click on the submit button, the request goes and
the response comes from the back end. (This is not an AJAX call)
Is it possible to see what data went as request and how the response came back from the back end? Are there any such tools to view the request / response if it's not an AJax Call?
By the way I am using Chrome and Apple browsers.
Use the Network tab of Web Inspector (Chrome/WebKit) or Web Console (Firefox) or the Net tab (Firefox with Firebug)
Another option than using a browsers native network inspector (which btw DOES work for non-Ajax requests), is to use an intercepting proxy.
Burp Proxy is particular nice. It allows you to see, hold and if needed modify both the request and the response between the browser and the server. You do need to setup your browser to use a proxy. It has a somewhat steeper learning curve than the browser's native network inspectors, but once you get the hang of it it's quite an invaluable tool.
I'm adding Box support to an iPad app. I tried the official SDK and I don't want to use it for the following reasons:
Login page is too wide for a modal controller with UIModalPresentationFormSheet style on iPad. The SDK hosts UIWebView which loads content of https://m.box.net/api/1.0/auth/, which perhaps returns HTML with min width set to 768px (although I didn't check the HTML, speculating here).
HTML in login page doesn't show Google Apps authentication option. The full desktop version of the page does.
Because the login page is hosted in UIWebView the user cannot be sure that he's supplying the credentials to Box, and not to an app author.
I don't need the whole SDK functionality, just authentication, folder/file listing and content download. Since my app also uses other cloud storage providers I'd prefer to provide uniform file browsing experience.
Here's what I'm going to do:
Add a custom URL scheme for my app, let's say "myapp".
In Box's Application settings for my app set Redirect URL to myapp://RedirFromBoxAuth.
When the user chooses to browse Box from inside my app, I'm going to:
Get a ticket by calling GET https://www.box.com/api/1.0/rest?action=get_ticket&api_key={API_KEY}
Extract the ticket, then call openUrl with https://www.box.com/api/1.0/auth/{TICKET} This will open Safari and let the user enter his credentials. This is the full, desktop version of the login page.
On successful login Box's server will tell Safari to redirect to myapp://RedirFromBoxAuth?ticket={TICKET}&auth_token={TOKEN}, which in turn will tell iOS to yield control to my app.
My app receives handleOpenURL notification and I can extract the authentication token and use REST API from now on.
Please comment, is it a good plan? I created a quick prototype and it seems to work, but maybe I'm missing something?
Box team, could you please tell us will an app using this authentication model be eligible for inclusion in OneCloud?
This seems like a good strategy and will probably make for a better UX/easier implementation than the normal redirect. Please let us know if you run into any weird edge cases by implementing it this way.
I am currently trying to port a Chrome extension to Firefox.
The Chrome extension has a "Login" page, which is opened in a new tab as an HTML document. The HTML document is stored in the local directory with other extension files. The user inputs a URL which should represent a server running our application, where the user will be asked to login. After a successful login, the user is redirected back to the options.html page, which is updated to show the user's preferences.
I would like to duplicate this in the Firefox extension, i.e. I would love to avoid writing anything in XUL to build an options page.
I tried opening a new tab with my HTML page like this:
var url = "chrome://myextension/content/options.html";
var win = Components.classes['#mozilla.org/appshell/window-mediator;1']
.getService(Components.interfaces.nsIWindowMediator)
.getMostRecentWindow('navigator:browser');
win.gBrowser.selectedTab = win.gBrowser.addTab(url);
But I don't like this for a few reasons: 1) The navbar in the new tab displays the "chrome:// ..." URL, and 2) it breaks the authentication process. The authentication is done using an OAuth type system, and the current URL is passed into the API so that the user can be redirected back upon successful authentication. The authentication fails with "chrome://" as part of the URL.
Just out of curiosity, I tried hardcoding the URL like this:
http://myextension/content/options.html
And the user is actually successfully authenticated, but then the redirect obviously fails afterward.
The Chrome extension seems to work with no problems or weird hacks. From what I can tell, opening it works like this:
chrome.tabs.create({"url":chrome.extension.getURL("options.html"), "selected":true});
And referencing the URL of the tab later so we can be redirected back to it just works like this:
var options_url = chrome.extension.getURL('options.html');
So, I'm wondering: what is the best way to open a local HTML document in a new tab with a Firefox extension, without using the "chrome://" "protocol"? Is there a similar way to how it can be done with Google Chrome extensions?
UPDATE 23/5/12
So this article says that chrome:// URLs are not accessible from the web, only locally.
http://adblockplus.org/blog/web-pages-accessing-chrome-is-forbidden
I think this could be the reason why my authentication was failing. I'm definitely looking for a way for my extension to display a local HTML file in a window or tab without using chrome://.
UPDATE 07/6/12
Here is my (hopefully temporary) solution:
The user enters the URL of the server running our application. He/she is redirected to the application login page, but instead of passing "chrome://myextension/content/options.html" as the URL to be redirected back to after authentication, I pass a phony URL, i.e. "http://myextension/thisis/madeup.html".
In my extension's overlay.js, I set up an HTTP request listener which listens for the phony URL being requested. When a GET happens for the phony URL, I cancel the request, and open the real, locally stored page at "chrome://myextension/content/options.html".
See the following references:
https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIObserver
https://developer.mozilla.org/en/XUL_School/Intercepting_Page_Loads#HTTP_Observers
If you're trying to do this redirect for an OAuth call you should try using OAuthorizer from Mozilla instead of doing the redirect work yourself. Hope that helps!