I have been searching around for a way to simply request webpages with HTML5. Specifically, I want to do an HTTP(S) request to a different site. It sounds like this is not possible at first due to obvious security reasons, but I have been told this is possible (maybe with WebSockets?).
I don't want to use iframes, unless there is a way to make it so the external site being requested does not know that it is being requested through an iframe.
I've been having a really difficult time finding this information. All I want to do is load a webpage, and display it.
Does anyone have some code they could share, or some suggestions?
Thanks.
Sounds like you are trying to to circumvent Same Origin Policy. Don't do that :)
If it is just the request you want (and nothing else), there are a number of ways to do it, namely with new Image in JavaScript or iframe. The site will know it is in an iframe by checking top.location.href != window.location.href.
funneling all your requests through a proxy might be a solution - the client addresses only the proxy and the actual url to retrieve would be a query string parameter.
best regards, carsten
Related
I made crawler with node.js. I want to crawl some sites on an hourly basis.
I tried to find out what user-agent I should use, but I only got results like google bot and bing bot. I don't know if I can use these user-agents.
Could you tell me which user-agent should I use?
Since you made your own crawler, you can come up with your own name. There's no rules around what the UserAgent may be, but many use a format like name/version, like:
myAwesomeCrawler/1.0
You could also include a url so website owners can find more information about your bot if they see it in your logs:
myAwesomeCrawler/1.0 (http://example.org)
But ultimately it's up to you.
This is of course all dependent on you doing something that's not illegal or violates the terms of service of the website you're crawling.
Depends on what you want to achieve. If you want to imitate a legit browser, simply take the useragent of a common browser like Chrome or Firefox. If you want to tell the site that you're a crawler, simply use something you define (e.g. xyzCrawler).
I have a situation where I have to make a centralized image website. I want to secure those images from direct access. I want to send response with a watermark over it depending on request parameter. What is the best approach for it.
So far I have created a content website and directly accessing image.
Should I create handler from response.
But if I use handler will it be slow (response).
Kindly suggest me the best approach.
An image handler is the way to go, you will be able to check the http header referer and only serve image when appropriate.
There is an article on the code project that has all the parts you need:
http://www.codeproject.com/Articles/126421/Image-Handling-In-ASP-NET
You'll have to ignore certain sections and expand on others, but there is basically everything you need in the article.
This might help you: http://www.naveenbhat.in/2012/06/directory-security-on-webservice-with.html
Here, I created the handler for html and pdf types. You can implement the logic in same way for image.
Is there a way to make a web app handle separate sessions for different browser windows/tabs other than having session id inside the URL?
In general form, what are the ways of storing session-id other than cookies and URL parameter?
I think you can try do it by using hidden fields in forms, but you have to create hidden form and make all links act as submit button (with some short JavaScript code setting proper value in fields responsible for target), but IMHO it is not the best solution, because all the requests will be using POST method and get all disadvantages of it.
And as question about other methods here is short list.
In short, no. You don't get any tab information from the client; a new browser window is just another client. The only way to differentiate clients is via cookies or parameters. Maybe you could create a tab-named cookie based on the javascript window object ID or something, but I kind of doubt it.
HTML5 (advert click-through, sorry) has some per-tab local storage options, but that probably won't help you right now.
Not sure if you searched before posting, but I found another question like yours - unanswered, but some good advice in the suggestions.
I implemented a script that monitors the iframe name as I understood was OK from various sources on the net. However it seems I must have gotten something wrong - I get
Error: Permission denied to access property 'name'
Source File: http://plungjan.name/test/testwindowname.html
Line: 16
Please visit http://plungjan.name/test/testwindowname.html
I would prefer just to fix my script and not use jQuery or DOJO or some other framework. Thanks
as I remember you must change iframe location to "about:blank" and after it you can access to its window.name property
Is it cross-domain communication you need here, or just the name of the window?
If the first one, take a look at easyXDM - it abstracts away all the hassle with XDM across browsers ranging from IE6 to Chrome10.
Take a look at this question:
Resizing an iframe based on content
Has a Cross Domain solution ... but you need to have access to both the servers to implement this solution.
As identified in C # where this is requested a specific web page, I wonder if the request comes from an image <img src="http://www.mydomain.com/default.aspx?n=123" /> or if the request is directly through an http browser, for example when the client is actually accessing the page via a browser sample: http://www.mydomain.com/default.aspx?n=123
See Finding the referring url that brought a user to my site.
You'll probably get more answers if you tag your question with ASP.NET.
No, it's not completely reliable. HTTP is in large part a cooperative protocol. That is, there are fields there that browsers can use to identify themselves and tell you where they're coming from, but nothing forces them to do it. The sad truth, unbelievable as it may seem, is that people might lie to you. They might say they're viewing your image from your Web page, when they really aren't. Or their browser might not tell you that it's viewing the image from your Web page. In general, the UrlReferrer thing works, but it can be defeated. Just as the browser identification string can be spoofed. We do the best that we can, and call it good enough.
I would expect the Request.UrlReferrer to be null when the image src makes the request.