I have an ASP.NET application that, among other things, is scraping another web site. I'm using a headless System.Windows.Forms.WebBrowser control in an STA thread, using Navigate(), handling the DocumentCompleted event, yada, yada. The WebBrowser control navigates to the remote site's login page (which uses javascript to fiddle with the DOM, thus the need for WebBrowser). I set the UserID and Password fields then I call WebBrowser.Document.All["submit"].InvokeMethod("click").
On my development box running Windows 7 and IIS 7.5, this behaves as expected. The next time DocumentCompleted fires, it's clear that I've successfully logged in and I go smartly about my business. On my Rackspace production server however, running "Windows Server 2008 Enterprise without Hyper-V" and IIS 7.0, it was failing: On that box, the next time DocumentCompleted fired, I would find that I'd received the remote site's "You've been logged out." page.
I tried adding the remote site to the Trusted Sites list, and disabling IE ESC for Administrators and Users, to no avail.
I finally managed to achieve the desired behavior -- the behavior I'd seen in my development environment -- by running this app in a special application pool whose identity I had set to Administrator. But I don't want to leave it that way.
What is the least privileged identity, or the minimum set of permission(s) sufficient on the application pool to allow this headless STA WebBrowser to properly browse this javascript-dependent remote site?
Related
I am developing web application on SAMSUNG devices, namely signage displays. That means TVs that are suitable for b2b long term use. We have been developing since Orsay and are currently developing on SAMSUNG's Tizen.
Basically we develop a web application, package it into a suitable Tizen widget using the Tizen SDK, put the widget and configuration on a server, connect a display to that server which will then download the application, install it and run it.
To monitor the application we are using Weinre. To do so we run a Weinre server and connect displays to that server using a line like this one:
<!-- WEINRE Remote include -->
<script type='text/javascript' src='http://thisissome.weinreserver.com:8081/target/target-script-min.js#WEINRE'></script>
When the respective page is loaded in the browser, a list of connections is displayed, there is a console available as well as a view of the DOM (basically like Web Inspector).
Now to my question.
I discovered recently that pressing F5 in the browser, while having one of the Weinre list entries selected, will not only refresh the browser page, but also force a refresh onto the web application that is being monitored. Put bluntly: I am loading the webpage that displays clients currently connected to my Weinre server. Then I select one of the entries displayed. Press F5. The browser window refreshes and the web-application on my display reloads as well.
Therefore I presume, something along the lines of
window.location.reload(false);
is being passed to the display-browser, because I can replicate the same behavior using this command to reload the browser page.
How does Weinre issue this command to the client?
Why does the reload trigger on F5, but not when manually clicking Refresh in my browser (here Chrome)?
Can I prevent this? E.g. could this be related to a setting of our Weinre server or some client setting? I scoured the Weinre documentation to find something related, but did find nothing. Could be a bug, could be a feature.
Hopefully I provided enough information. Apologies if something is missing.
I have some troubles to start my WebApp with Chrome (not always).
My webApp is a simple Javascript App and it's loaded using HTTPs. The server providing the WebApp resources is using a self signed certificate that is not trusted by Chrome (same for Firefox...).
When a user starts for the first time the WebApp (or after cleaning the Chrome's cache) using an URL like https://mywebapp:8443/ui the user gets a message that the website is not trusted (ERR_CERT_AUTHORITY_INVALID) but the user can continue (it's the expected behavior).
Next, there's the issue: Chrome starts loading my webApp by getting the index.html and then the .css but it's unable to get the .js that contains the Javascript code of my webApp.
In the Chrome Development tool, I can see the response of the HTTPs request to get the .js file is "Failed to load response data".
I don't understand why there's this error with Chrome (it never happens with Firefox).
Next, if I reload the page in Chrome, the WebApp is successfully loaded and displayed.
I can reproduce this issue when I'm cleaning the cache in Chrome. If I'm not cleaning the cache the WebApp continues to work even after a Chrome restart.
Can it be due to the self signed certificates? What can be the reason of this issue during the first start? Why it happens only with Chrome?
Thanks for your help,
I guess it's due to using a self signed certificate,the newest Chrome Brower don't allowd trust self signed certificate,so your own certificate is not trust by chrome!
You can into chrome://net-internals/#hsts in brower address blank,then delete 'localhost' in HSTS list.
I was wrong, the issue was also appearing in Firefox.
I have found the root cause, it was due to the backend that uses a Kong cluster between the WebApp running in the web browser and the tomcat server that is located behind Kong.
An important things is that I'm also working in a DC/OS environment and between the WebApp and the Kong there's a marathon-LB !
Ok, the issue is the marathon-LB is dispatching the requests from the WebBrowser to one of the Kong from the cluster. Each Kong has its own self-signed certificate and as a consequence, the web browser gets responses from the same IP# signed with different certificates (since each request is managed by a different Kong).
When I configure the Kong cluster with only one instance everything work well because it's always the same Kong that is responding and all requests are signed with the same certificate.
The solution is to configure the marathon-LB with a certificate and then only this one will be forwarded to the WebBrowser instead of the Kong certificate.
I have developed a chrome extension which does particular job and tries to connect back to a java desktop application.
Now what I want is, the chrome extension should get enabled only when desktop(java) application is opened and similarly it should get disabled whenever I close the desktop application.
Can I manage this using java?
Or any other way/ CMD is it possible?
Basically, you would need some ways to exchange message between extensions and native apps, for this purpose, there are many optional ways, such as Native Messaging, WebSocket, or simple http server/client.
Depends on what you choose to use, the implementation details may differ. However their ideas are similar:
Start the connection from extension and keep the connection for each side
Save a flag in extension side to mark whether your extension should be enabled
Once the connection is lost, revert the flag and disable the functionality of the extension
So, I'm building a Guest Internet portal for a public hotspot in a hotel. This means the portal is served through a Network Access Gateway (a Nomadix) that redirects all outgoing traffic to the portal page. The portal needs to be able to set cookies on the browser so that Guests can be automatically logged back in after they idle timeout.
The Problem:
iOS4+ and OS X (10.7+) Devices have a feature called Captive Network Support. This feature continuously scans for Wifi SSIDs, connects to them, and curls http://www.apple.com/library/test/success.html to see if the device is connected to the internet. If it doesn't get the Success response, these devices pop open whats called a Captive Network Portal. This portal is not a true version of Safari Mobile and you cannot save cookies on this browser.
I would like an authoritative answer to the following question:
With client-side javascript/markup can I?
A) Save cookies within the Captive Network (popup) browser
B) Prevent the Captive Network browser from popping up in the first place without whitelisting apple.com
This is kinda the wrong site in the StackExchange network for sysadmin stuff; you may wish to try ServerFault. In my experience as a user, there are WiFi portals out there that manage reauthentication without cookies; perhaps ServerFault can help you find such.
That said, there's one possible solution in terms of iOS client-side development: There are CaptiveNetwork APIs which allow a third-party app to inform the system that it's assumed responsibility for authenticating to particular SSIDs, suppressing the web sheet. It's likely not a desirable solution, since it requires your users to install an app, but it's there.
You could try serving "http://www.apple.com/library/test/success.html" locally when ever an iOS device is detected. This will make the CNA not pop up and then the user could login through mobile safari, in which you can save cookies.
iOS 14 has a new API for work with a captive portal. Btw, Android supports it too
I've thought about using Chrome and HTML5 local storage to create a useful app and sell it. The problem I think I would have, however, is the delivery mechanism to get this installed on one's computer. Let's say the app was wikipedia.com (although it isn't). Manually one can go there with Chrome, then choose the wrench icon, Tools, Create Application Shortcuts, and make a desktop and application menu icon for the app.
Okay, fine, but is there a way I can compose a web page link or form button such that it does this for me? In other words, one clicks a button or link and it shows the Create Application Shortcuts form. I am hoping that there's this little-known way on Google Chrome to use either HTML or Javascript to trigger showing that form.
As for those who don't have Chrome, I can detect that and give them a button they click that emails them. In the email, it will give them instructions for installing Chrome and then another link so that they can visit this page in Chrome in order to get the button that shows the Create Application Shortcuts form.
For now, until a better answer can be provided, this is sort of the technique for deploying a desktop app with Chrome, the manual way, and without having to register in the Chrome Store:
After the user purchases a product, email them the serial number for registering their product and a web URL to install this new product.
The web URL is the actual URL of the web app. However, it doesn't display its normal content by default. Instead, the web app is in "installer mode". It does this by looking at a 200 year persistent, encrypted, registration cookie that may not already be installed. (Note if they delete cookies, there's no harm done -- it just asks them to re-register again.)
The first thing the web app does in Installer Mode is detect user agent. If it finds this is not Chrome, it gives them a link to install Chrome and tells them to follow the instruction email again that they have already been sent, but using Chrome to do this. (You might also want to provide a form to resend them the instructions and serial number again.)
The user either installs Chrome and returns back to this page again, or is already a Chrome user. The Installer Mode then shows a message that reads, please press the ALT-F key in Chrome, or press the Wrench icon in your toolbar, and choose Tools > Create Application Shortcuts, check the two checkboxes, click OK, and then click the "Task Performed" button below.
The user follows the instructions and creates their desktop/application shortcut and then clicks "Task Performed".
The user then sees a registration form where they are to type in their serial number they were emailed. The user enters this in and clicks the Register button.
The server validates the registration and then stores a persistent, 200 year encrypted cookie that basically says, "This guy is registered." This keeps the web app from running in Installer Mode.
The Installer Mode is still active, however, and shows them the final prompt: "You may close your browser and run the icon for the new app from your desktop or application shortcut that you created. The icon is named '{insert name here}'."
They close their browser and doubleclick the icon. The application loads, the registration cookie is read, and the web app no longer runs in Installer Mode -- it shows the application content like it normally would. Besides the fact that this is not a 100% truly automated install, the only drawback is that, since the main page is not a local file (cached), the web app can't really work offline completely. Sure, it can use HTML5 offline storage, but doubleclicking the desktop shortcut will always connect to your web app site.