I want to set up a home page when people connect to my wifi, and there ask for a username and password and depending on the answer connect them or not, to the wifi.
What do I have to do? Or how is this call, to search it up on internet that I couldn't find it.
Thank you all!!
This sort of page is called a 'Captive Portal' and is a common feature of Wi-Fi APs and some Internet gateways.
It's considered poor user experience and generally does not add much in terms of security and access control over what Wi-Fi provides.
Related
Is it possible for let’s say a hacker to obtain a list of users connected to a WPA2 secured WiFi, if he doesn't know the password and will not be able to obtain it in any way ?
Yes kind of.
You can read out the MAC - Addresses of connected devices without having the passkey. You just would have to run a passive scan.
The MAC - Address is not necessarily unique as you could change it on most devices.
Needless to say:
It's illegal to obtain such data in other Wifi's than your own as this is a breach in personal privacy.
I'm building a commercial esp8266 device. I need it to connect to WiFi to use the device with an app.
I managed to connect it via both WPS and Access Point (getting the SSID and Password from the app by connecting to the Access Point).
I'm trying to understand which of these two would be ideal for commercial use.
WPS compromises network security until a device connects but it is super fast.
AP doesn't compromise security but it is slower + the user loses his WiFi connection until he passes the SSID and Password.
Another problem is that people might not be able to find the WPS button on their router.
Which of these two methods of connecting to WiFi should I use?
So, essentially what should I choose between Speed and Security?
Edit: It's important to note that multiple commercial devices use WPS to connect (printers for example).
In a commercial setting using WPS makes no sense at all, just use the access point information as you do not want to have any chance of security breach.
Google just announced that they will add support for VoIP calls in its Gmail application.
Does someone know how this will work? Did they manage to write a web-based VoIP client, or will they require the user to have Google Talk installed and somehow (how?) call this app from the browser?
I'd also like to provide customers with a way to make/receive calls through their browser, so that they wouldn't have to install an SIP client.
Thank you.
Google don't use a VoIP client in a browser. Instead the browser is used to initiate a callback to a phone number you must have previously registered. Once you answer that call Google Voice will then ring the destination number you specified and then bridge the calls together.
I've just noticed that in my inbox. They ask you to accept their EULA to start installing Google Voice. So it's not really a browser solution.
There are several companies that have built VoIP clients as e.g. Java applets.
It is totally doable, although depending on the exact requirements it may be expensive and time consuming: for instance, echo cancellation is not exactly trivial when you need to deal with arbitrary audio drivers across any and all laptops, netbooks etc out there.
There are also consulting firms that can help with that.
Full disclaimer: I own one such company ;)
Suppose you want to add an extra layer of credentials on top of a SSL-encrypted login/password, but you don't want to increase complexity to the user. Is there a way to add the requirement of the possession of a dongle to web-server authentication schemes with existing cross-platform browser capabilities?
In other words, to get access to the web-site, you would need a username, password, and a USB dongle that has been plugged into the client computer. The dongle would presumably do some sort of challenge/response.
It'd be ideal if this dongle solution worked with Firefox automatically or with the simple addition of a plugin.
Thoughts and suggestions are appreciated.
You may be interested in the Yubikey.
It's a small usb dongle that acts as a usb keyboard (i.e. needs no special drivers or client software) and is designed exactly for this sort of authentication.
You could use RSA SecurID tokens, which are little keychain displays that change the number displayed every one minute. In addition to requiring the username and password, you can also require them to enter the number they see on their token to verify they have the hardware device with them. There are various hardware dongles, with some even requiring a PIN to be entered to see the changing number. The is extra complexity on the server side, but the client doesn't have too much trouble.
I've also used the Yubikey with good results. Another similar solution is the Swekey - you might want to check that out also.
I've had good results implementing website authentication and login using Dinkey Dongles and the DinkeyWeb system.
The user plugs the usb security dongle into their machine, visits your "protected" web page and it validates the dongle before loading the page. Works without special permissions or privileges.
Hope it helps.
It's going to require something that has the rights to access the dongle. There is also the issue of hacking it--the communications aren't going to be able to be hidden so you have to make sure it doesn't matter. That means the dongle is going to have to implement it's own crpyto. You'll also need support for whatever systems you are going to support.
I see this getting very complex very fast.
Midlet using HttpConnection to connect a webservice application.
A mobile can use a wireless broadband to connect to internet or can use internet facility provided by the network provider i.e. Vodafone or Virgin which is I think known as GPRS. Correct me if my understanding is wrong.
Now my question is when the midlet will run which connectivity it will use? Secondly do I need to code differently for midlet to use GPRS or it doesn't matter?
I deployed my application on Nokia E65 and it asked me which connection to use. The mobile had both wireless lan and provider GPRS active.
On IPhone the preference is for wireless lan. (Not related to J2me)
There is no standard Access Point Selection APi in J2ME.
That means the MIDlet itself can't decide whether to use Wi-Fi or GPRS.
Some phones will allow the user to change application settings in order to force a MIDlet to use a specific network when it is available (and maybe prompt the user for an alternative when the preferred network is not available).
This is mostly because there is no standard way to describe a wireless network that contains enough information : QoS, cost per byte downloaded and uploaded, average bitrate, ping time...
In most cases, the logic to automatically choose a network without those information would be too complicated and not reliable enough.
Manual Access Point selection is the only way to put the user in charge of the cost of data transfer, so far.
It depends on the client mobile phone. On some models, there is only one GPRS configuration that is used by all applications including midlets, On some others the configuration used for browsing can be different than the one used by midlets.