I have the following problem to solve:
I few months ago I startet a website where you can watch youtube videos which aren't available in your country. Everythings works fine but now I want to offer a new method where I route all the requests directly over my server. Therefore I will later use a custom DNS-Server. Right now I use the hosts file for testing but I have really no idea how i can identify the user. I can promp the user user to login on a website but I will that it works systemwide so if he use a youtube downloader for example it have to work there either and not only in the browser where I could use a session system with cookies. I want a solution where the user can identify himself once in a time like a website or something like this but how can my server detect if this is a user which is logged in or if he is not?
There are several ways that this could be accomplished with varying levels of difficulty.
standard proxy server over https. Your service could simply be a proxy server and then every "client" would update their browser to point to your proxy server. You could also simplify this by using a proxy PAC file (proxy auto config).
An anonomyzing interface. The end user would not be able to use their standard search tools etc, instead they would have to use a web page much like what google translate does.
A browser plugin. There are already firefox plugins which do something similar to this. They change the way that the browser resolves DNS. This may be the best bet for you but would require development work.
An actual install utility that you have your users install on their machines which update the dns servers.
Related
We're using AppAuth for a macOS application to authenticate Google accounts. This has been working for years, except recently Chrome has started to block all http connections by default. The loopback server in AppAuth is hard-coded to work with http connections only. The following issue also seems to have gone unanswered: https://github.com/openid/AppAuth-iOS/issues/624
What other options do we have for using a https loopback server on macOS for OAuth2 authentication? We need the loopback server to be able to extract parameters Google sends back after authentication. Asking users to switch from Chrome is not desirable.
Interesting - with loopback desktop logins there are two URLs involved:
The URL in the desktop app, which is meant to be HTTP according to OAuth standards, since it runs on end user PCs. Using HTTPS would require the entire user base to host SSL certificates, which is highly impractical. Typically a loopback URL is a value such as http://localhost:8000, where the port number is often calculated at runtime.
The URL used to invoke the system browser is a value such as https://myauthserver/authorize?client_id=xxx&redirect_uri=http://localhost:8000..., and this should be HTTPS of course.
PROBLEM DIAGNOSIS
I'd be very surprised if Google have blocked this if you are using standard desktop logins, since it has been referenced on their Native Apps Page for years.
Are you sure something else is not the cause? One possibility might be lack of a user gesture in the system browser. Is the problem consistent and are there any differences in these cases:
Make Safari Browser the default before login
Make Chrome Browser the default before login
Make Chrome Browser the default before login and clear browser cache
Let me know and I may be able to suggest some next steps ...
I do automation testing for a company that is trying to implement a single sign on via an iFrame; a third party site will include our page in an iFrame and we will do an authorization.
We had to rework the way this worked because of Firefox defaulting to 3rd Party Cookies being off. For manual testing, we have hosted the page on a different domain, but this domain requires certain usernames and passwords we cannot expose in code, so this is difficult to automate.
Is there a way I can trick Firefox into thinking that mydomain.com is not actually mydomain.com? This sounds impossible, because if I can trick Firefox into thinking I'm actually on mydomain2.com, then I can effectively just put on a 3rd party cookie, but since I'm doing it on my own instance of Firefox, are there any settings I can change in my profile to confuse it?
Yes, this is incredibly easy and we do this all the time.
Log onto the test machine (the computer that will be running the browser) and edit the hosts file, located in c:\windows\system\drivers\etc
Add an entry for the site you wish to be confused, using a different domain name but the correct IP address. Because it's a different domain, it'll look like a third party site, but because the IP address is the same, the requests will actually be sent to the same web server.
Example:
Assume your web server is running on the local host (which has address 127.0.0.1)
Add host entries for
127.0.0.1 FirstPartyDomain.com
127.0.0.1 ThirdPartyDomain.com
Access your site via http://FirstPartyDomain.com
Site contains an iFrame
<iframe src="ThirdPartyDomain.com/SetNastyCookies">
The request in the iFrame will go to the same server (local host) but in the context of a third party site.
What about using DNSMasq? Most open-sourced routers such as DD-WRT support this option. If you need to test it via https, you could also temporarily store security certificate exceptions as well during your testing.
A bit of a generic question but let's say you have a desktop app that allows a user to connect to a central server and provides functionality like:
Login
Ability to auto-download profile data on login
Download and uploading save files through the app
A web-server (JSP/ASP.NET/PHP/etc) would do lots of work for you especially on the request-serving and threading front, but it seems a bit of a cheat for a desktop app to use HTTP requests like this.
All thoughts welcome. Maybe this should be community wiki?
If you want to leave things open for other possibilities in the future, go with a web server. That way, if you decide to write a web-based version of your desktop app (or an iPhone/Pre/Android application), you don't have to rewrite your socket server. Almost everything can speak HTTP these days.
I have a site i am working on that i would like to display only to a few others for now. Is there anything wrong with setting up windows user names and using windows auth to prompt the user before getting into the development site?
There are several ways, with varying degrees of security:
Don't put it on the internet - put it on a private network, and use a VPN to access it
Restrict access with HTTP authentication (as you suggest). The downside to this is it can interfere with the actual site, if you are using HTTP auth, or some other type of authentication as part of the application.
Restrict access based on remote IP. Just allow the IPs of users you want to be able to access it.
Use a custom hostname. Have it on a public IP, but don't publish the hostname. This means make an entry in your HOSTS file (or configure your own DNS server, if possible) so that "blah.mysite.com" goes to the site, but that is not available on the internet. Obviously you'd only make the site accessible when using that hostname (and not the IP).
That depends on what you mean by "best": for example, do you mean "easiest" or "most secure"?
The best way might be to have it on a private network, which you attach to via VPN.
I do this frequently. I use Hamachi to allow them to access my dev box so they can see whats going on. they have access to it when they want , and/or when I allow. When they are done I evict them from my Hamachi network and change the password.
Hamachi is a software VPN. Heres a link to Hamachi - AKA LogMeIn
Hamachi
They have a free version which works quite well.
Of course, there's nothing wrong with Windows auth. There are couple of (not too big) drawbacks, though:
your website auth scheme is different from the final product.
you are giving them more access to the box they really need.
you automatically reimaging the machine and redeploying the website is more complex, as you have to automate the windows account creation.
I would suggest two alternatives:
to do whatever auth you plan on doing in the final website and make sure all pager require auth
do a token cookie based auth - send them a link that sets a particular token in a cookie and in your website code add quick check for that token before you even go to the regular user auth
If you aren't married to IIS, and you need developers to be able to change the content, I would consider Apache + SSL + WebDav (aka Web Folders). This will allow you to offer a secure sandbox where developers can change and view the content without having user accounts on the server.
This setup requires some knowledge of Apache so it only makes sense if you are already using Apache or if you frequently need to provide outsiders access to your web server.
First useful link I found on the topic: http://pascal.thivent.name/2007/08/howto-setup-apache-224-webdav-under.html
Why don't you just set up an NTFS user and assign it to the website (and remove anonymous access)
I have a website in which I want to be able to detect a certain user based upon a permanent attribute of a specific user.
My original plan was to use an ip address but those are difficult to maintain since they can change frequently.
Cookie's and Sessions are almost out of question because they expire and tend to be difficult to manipulate.
Basically what i want to be able to do is detect if the current client visiting the website is a special user without having to deal with logins / passwords. To use something more permanent.
The user agent plugin could work but then, if i ever upgrade firefox or whatever i would have to go in and manually update the user agent string.
I found this script: https://addons.mozilla.org/en-US/firefox/addon/6895 but it doesn't work for newest version of firefox 3. It would be a perfect solution because it sends special headers at specific websites.
Short of writing my own extension does anyone have ideas of what to do? Do i need an extension? Should i try to write my own?
You could generate a SSL client certificate, and have your users install it. From then on, their browser would identify them using their certificate.
HOWTO: Securing A Website With Client SSL Certificates
SSL and Certificats (IIS 6.0)