When trying to login in to Hotmail I get a Javascript Redirect. Is there a way to avoid it?
IdHTTP1.Get('http://www.hotmail.com');
Cookies must be allowed Your browser is currently set to block cookies. Your browser must allow cookies before you can use Windows
Live ID.
Cookies are small text files stored on your computer that tell Windows
Live ID sites and services when you're signed in. To learn how to
allow cookies, see online help in your web browser.
JavaScript required to sign in Windows Live ID requires JavaScript to sign in. This web browser either does not support JavaScript, or
scripts are being blocked.
Indy will not pass up a recognised user agent for you, you'd probably have to set that yourself. Also as it states you need JavaScript support, which Indy will not give you.
Your only real option is to automate something like IE, WebKit or Gecko or wrap some headless browser like PhantomJS.
Related
I am preparing to work on a project where I need to display a dashboard from an online application. Unfortunately, the use of an API is currently not possible. The dashboard can be embedded in an iFrame. However, when it is displayed it will prompt the user viewing the dashboard to login to an account.
I have one paid account to this service. Are there any rails gems to login to the service before the iFrame is processed?
Or would a proxy within my rails app be a better route to go?
Any pointers are appreciated!
Neither a Rails gems nor a proxy within your rails will work and they same have the same limitation.
They are both running on the back-end, server side.
The authentication you need is client side.
Unless you mean proxy the ENTIRE thing, the auth request and all subsequent requests and user interactions with this dashboard. That should work but (see below)
The way authentication works (pretty much universally) is: once you log in to any system, it stores a cookie on your browser and then the browser sends that cookie for every subsequent request.
If you authenticate on the backend, that cookie will be sent to your rails code and will die there, and the users browser will never know about it.
Also - it is not possible to do the auth server side and capture the cookie and then have the user browse the site with their browser directly, for two reasons:
Sometimes auth cookies use information about the browser or HTTP client to encrypt the cookie, so sending the same cookie from a different client wont work
You can not tell a browser to send a cookie to a domain different than your own.
So your options are, off the top of my head right now:
If there is a login page that accepts form submissions from other domains, you could try to simulate a form submission directly to that sites "after login" page. (The page the user gets directed to once they fill up the login form). Any modern web framework as XSRF protection (Cross Site Request Forgery protection) and will disallow this approach for security reasons.
See if the auth this site uses has any kind of OAUTH, Single Sign On (SSO) or similar type of authentication integration that you can do. (Similar to an API, so you may have already explored this option)
Proxy all requests to this site through your server. You will have to rewrite the entire HTML so that all images, CSS, stylesheets, and all other assets are also routed through the proxy or else the URLs are rewritten in the HTML to not be relative. You might hit various walls if a site wasn't designed for this use case. From things like the site using relative URL's for assets that you aren't proxying, the site referencing non-relative URL's causing cross-domain errors, etc. Note its really hard to re-write every single last assets reference, its not only the HTML you're worried about, Javascript can have URL's in it too, and CSS can as well.
You could write a bookmarklet or a browser extension that logs the user into the site.
Have everyone install Lastpass
Have everyone install the TamperMonkey browser extension (and others like it for other browser), and write a small User Script to run custom javascript automatically to log the user in on that site
Scrape that site for the info you need and serve it on your own site.
OK I'm out of ideas. :)
I am helping to create a Rails app that uses Ember for a front end MVC. For the app, it is hosting user content accessed via subdomains. On the subdomains, the user can upload custom JS and CSS. What I'm wondering about is if token authentication on the root domain will be safe if stored in Ember from the custom JS people could upload and run on their subdomains?
Provided the following:
Don't use cookies on *.domain.com or use cookies at all.
They can't run (or really display it unescaped in any way) the JS/CSS on your main site.
The ember app with your token doesn't run on their sub-domain (obviously).
They can't put HTML in a file with a different extension or even Content-Type on your subdomain (or you aren't using cookies). They could direct a user's web browser there and it'd display the HTML. Be wary of phishing though (looks like it's your secure content). I can't imagine you could prevent this easily other than not using cookies -- without 100% ensuring properly formatted JS/CSS which would present all kinds of problems.
You can limit cookies to domain.com and www.domain.com, but I don't recommend it (prone to mistakes). If you don't somebody can make a GET request through CSS or ie. an image tag (not to mention JavaScript) and it'll send the authenticated cookies to your server. Remember unescaped input in their app can leave holes too.
If your token is stored in ember, and they have access to custom JS where the app is running of course it'll leave your token vulnerable. If you run your ember app only on the www.domain.com, avoid cookies, storing the token only locally/in JS, you might be okay.
If they just put HTML code in a file with another extension and direct people there it'll be interpreted as HTML.
I am looking to create a browser written in HTML using AsYouWish. (AsYouWish exposes the privileged Firefox Addons SDK to regular websites, subject to user approval for each privilege requested by the site; note, however, that this question doesn't really require knowledge of AsYouWish, just the SDK or XPCOM APIs.)
My demo is able to make a cross-domain request and add the text to the iframe using srcdoc, but due apparently to security restrictions, I can't get a contentDocument out of the iframe (as when I try to change the src on an iframe instead, as per this demo).
Is there some kind of means (content-proxy, security policy, or whatever it may be called) in the Addons SDK (or XPCOM) I might use to escalate my website's privileges to introspect the (cross-domain) contentDocument here (so I can listen in from the parent for page location changes in the iframe and thus build my own browser history with back and forward buttons, etc.)?
UPDATE: Since I understand remote XUL has been disabled, I am thinking that perhaps my only (albeit awkward) solution might be to detect a request by a site for DOM privileges, and if granted by the user, reload the page within a privileged iframe of a chrome:// document (since as per https://developer.mozilla.org/en-US/docs/Displaying_web_content_in_an_extension_without_security_issues the inner iframe will be granted privileges in this case unless restricted and thus presumably the privileged iframe should be able to reach into its own (cross-domain) iframes). I wish I could allow it access into its cross-domain child frames without access being able to come out of it up to the chrome level, but I can probably live with that since granting cross-domain iframe access is already a very high level privilege.
Assuming I have internet browsers like mozilla and iexplorer, so, I used mozilla and I have already logon to a website using my account username and password logged in, well idhttp can post(submit form, automated click) to the already opened account(without opening the web browser)? OR I will have to used again my username and password to post a submit?
I dont need a code, just asking for answer YES or NO, and if NO! what control in the INDY should I use in my approaced?
Sample: I want to automate a submit button for a click(my account is already logged-in)!
thanks
There is no simple YES/NO answer to your question. It depends on how authentication is handled by the web site/server.
By default, http is STATELESS: each call into the server knows nothing about the previous call. In that case, you will have to authenticate EACH TIME you hit the server.
But most modern sites implement some kind of authentication persistence: either by maintaining user session information on the server, or, as Arnaud Bouchez mentioned, sending back a cookie that keeps track of your authentication.
I once wrote a custom web application that sent back an encrypted authentication token with the first response, and it was the client's (it was a custom Windows client with an embedded socket implemented using idhttp, not a browser client) responsibility to send back that token for each subsequent request.
So, your answer is: Let the server handle it - you generally don't have much choice.
I suspect the authentication will be local to the browser, i.e. validated via a browser-specific cookie.
From the Delphi code, you would need to retrieve the cookie (it may be possible, e.g. from a SQLite3 file with FireFox, or as plain text in user profile with IE), then use Indy to query the web site, including the cookie content within the request headers.
But it will highly depend on how the authentication is done. For instance, does it use HTTP or HTTPS protocol? How is implemented the server side?
How about creating a custom browser with a function to auto submit after you login to the site?
I ever make a custom browser with an auto form submit function using TChromium and TBrowser.
It's easy. You just need to know how to control dom using javascript and also manipulating the page source.
Sorry for the simple answer
I am trying to write a script that will provide XML data to a third party client. I wish to require that all clients are authenticated in order to make use of the system.
Rather than using a bespoke authentication system, which would be overkill, I want client applications to just pass in their credentials via the url, such as http://myusername:mypassword#mysite.com/. This is not unlike how it is done in FTP.
I think this is possible using .htaccess, but when I do try it, I still get a dialog prompt asking me to login or confirm the credentials that I will be using to login. Is there a way that I can suppress this in the .htaccess or an alternative way of authenticating on the server?
This is probably a security fix of the Internet Explorer, which was introduced by Microsoft some years ago. If you retry it with Firefox, it should work.
If you want to allow the Internet Explorer to login via the given username and password, check out this Microsoft article on the theme, especially the workaround section. And btw, the url is supposed to be http://username:password#example.com (note the double-slash).
Also, please make sure your .htaccess is correct by entering your login-information in the credentials popup - you should be able to login anyways.