I am looking for ways to browse sites that are blocked by proxy filters at my location.
One solution i came up with was to build a page that would take a input of a URL and display the site in an iframe. Thus i would have a window into a browser on a page that is being displayed by my proxy. I was going to host this on my personal web site and use it to access restricted content. this way i have access to blogs, and forums where there is a wealth of information that is blocked by a backwards blanketed restriction list.
How can i make a web page similar to this? Would it be simple html and javascript, do I need .Net?
What you aim to do has to be done server-side. When you put a page in an iframe, your web browser loads it, and will do so just as if you went directly to the URL.
There is no way around this via client-side code, such as JavaScript.
If you truly want to reinvent the wheel, pick a language and look into whatever functions download files. No need to do this though when there are plenty of web-based proxy services, such as http://www.hidemyass.com.
Even if you loaded it in an iframe, the request for the page in the iframe will still go through the proxy and so you will still be blocked.
You'd have to do something like open a socket to the site through your web host and then download the content and redisplay it. That's assuming your host isn't also blocked. Also, you'll lose the benefits of cookies and sessions this way (ie. you won't be able to be logged into things unless the session id is in the query string).
The fastest and simplest solution would be to create a free Log Me In account at www.logmein.com. then setup your host computer at home, login from work, and browse freely. I do this myself at work so no one can see my personal browsing history when I dont want them to. This of course would only work if logmein.com was not a blocked site at your work. good luck!
It depends upon the "filter" complexity. If you have your own website that you can reach through the proxy or if your computer can run as a webserver, you could try accessing via a proxy script such as "CGIProxy." There are online services that do this too. However, some proxy filters can detect these methods as well and you'd still be out of luck. No javascript or HTML tricks can overcome the proxy filter.
Related
I need to launch a web browser window from my .NET application that shows a web page that can be arrived to only by a POST request. I am definitely not allowed to do this with a temporary HTML file that contains a POST form. Any ideas how to solve this in another way? I have no idea what browsers are installed on users computers and I do not wish to have any requirements regarding this. Default browser would be the best.
Edit: Ok, as soon as I read my own question, I see one solution: to host e.g. a php script on my own server which would convert GET requests to POST requests and redirects to that web page. That php script can then be accessed with a simple link from my .NET application. Obviously, this involves an additional delay and complicates matters. Is there another solution?
No, there's no better solution other than the two you describe. https://textslashplain.com/2020/02/05/app-to-web-communication-launching-web-apps/ outlines the problem space.
I would like to gather some feedback on how best to handle access control within a web application that has a requirement for offline use.
The app must have access control via username/password but must be available for offline use. That means that the first time the user logs in, the user must have an internet connection. Once logged in the app will set an acl cookie followed by caching all assets through cache manifest.
Is this a solid approach and what other methods have you used to solve this issue?
Thank you in advance for all your feedback.
Answering quite late but even if you no longer need it someone else will...
Once offline, you need to store all access info on the device. It will be accessible by third parties so there will be a matter of time before someone will have access to all your app content. I explain to clients that once you publish something for offline use, it's there for anyone to see. You can implement some basic login but unless you use an online service, it's not going to be any secure...
Giving that, use local storage to keep track of initial login. Then, refresh it every so often when device goes online.
I would like to develop a webpage (using any technology) with these conditions:
When client A types the web address on his browser, they automatically receive a remote IP (no other data)
With this IP, Client A automatically request some data from that IP (Client B)
Client B sends the requested information to Client A.
Which technology and libraries could I use to develop this webpage? (Javascript, Applets, browser plugin...) I think is some kind of P2P, so it should be possible to develop it.
Let's put one example.
Imagine that the webpage I have to program is www.hi.com/test.html.
I type it on my browser and receive automatically this IP: 212.22.62.106
My browser automatically request data to 212.22.62.106, which is another client of www.hi.com/test.html
This second client sends me the requested information, which is the only one is shown on my browser.
THANKS
Just about everything in browser security is going to fight this model - Ajax, javascript in general, applets, cookies - they're all tied to the current domain.
To do this, you're going to need to get something onto the desktop, if only in the form of an ActiveX control, which will severely limit your browser-base.
I think you're barking up the wrong tree - maybe if you could pop up one level of abstraction and tell us what you're trying to accomplish with this model?
This is not possible with web page, you're looking in the wrong direction.
You'll have to build your own application which by the way sounds really similar to eMule.. :)
I have been tasked with securing a pure HTML website for someone, and I'm not entirely sure how to approach the problem. Here are the constraints:
All logins must link in with our current Active Directory domain.
(Optional, but desired) The solution must whitelist requests coming from inside our intranet - that is, if someone attempts to access the site from on campus, they are immediately allowed in.
(Optional, but desired) The solution must whitelist requests made from our hub website, regardless of whether or not they are on campus. Said hub site is secured with logins that reference our Active Directory domain, so this is essentially a request for a passthrough.
The vast majority of our user base is very non-technical, so as small a footprint with few requests for logins is nessecery.
Normally, I'd have no problem with this, but this is a pure HTML website so my options are a little limited. My current ideas:
Use IIS6's Directory Security to simply force Active Directory authentication. I cannot use the IP permit/deny because that check comes before anything else in the life cycle and quickly denies anything on the deny list. I cannot change this behavior.
Code an aspx file that resides on our hub website that pre-loads the integrated Windows security credentials for the user, automatically authenticating them to the HTML website. As far as IIS is concerned, however, these are two different websites and this sounds like bad practice at best and an imitation of a cross-site intrution attempt at worst.
I have to admit I'm stuck. Has anyone ever handled a problem like this before?
Assuming you are using Windows2003/IIS6 and your web server is part of your domain you can do the following:
Configure your website to use Integrated and/or Basic authentication to authenticate against Active Directory. Also disable anonymous access. You'll find these settings by clicking "Edit" in the "Directory Security" tab of your website in IIS Manager. You'll only need to enable Basic if your users will use a browser other than Internet Explorer. If you use Basic your should also use SSL to protect your usernames and passwords. The level of access is determined by the permissions set on the files/directories on your website's root/child directories. Any files within these directories will only be served to authenticated users.
To allow users on your domain to logon without a prompt you will need to configure Internet Explorer to automatically logon to sites within your intranet. You'll also need to enable Integrated authentication for your website in IIS.
I'm not sure if the requirements in item #3 will be met. If your hub website uses impersonation it might pass your Windows credentials to another server within your domain but I suspect not.
References:
"How to configure IIS Web site authentication in Windows Server 2003"
http://support.microsoft.com/kb/324274/
"Internet Explorer May Prompt You for a Password"
http://support.microsoft.com/kb/258063
"How to use security zones in Internet Explorer"
http://support.microsoft.com/kb/174360/EN-US/
If the pure-html site is running on IIS, converting it to a .Net web app just to wrap its resources in your custom conditional forms login using the richer ASP.Net security wrappers seems like a natural enough fit. You can serve the pure HTML files out of that now-application.
This has no downside for the content maintainers that I can see.
We are trying to streamline the process of showing clients their websites whilst in development without the need to change absolute paths etc.
We mostly develop locally and change our hosts files to reflect the domain name, when we are ready to show the client we copy the files to www.client.com/dev but I'm looking for a better method, any suggestions that can make this process smoother and faster would be great.
If you always host the site on a separate domain and not in a subdirectory, you will never have to change absolute paths. So instead of hosting a site in development at www.client.com/dev try dev.client.com. Another option would be to use client.yourcompany.com.
Also try to protect the site in development with HTTP basic authentication. This is easy to set up in most web servers, without changing your web application. Also, if the content is even remotely sensitive in any way, use HTTPS as well.
Alternatively, let them simply come over to your office and present it to them (or go to them and present it). The upside is that you have full control over what they will and won't see, and it never has to go online.
Well, we have client.t.uw.ru site which is universally visible.
When it matures, it moves onto www.client.com and is pushed to search engines.
Thus, we have a * DNS entry on t.uw.ru domain which makes it easy.