• 6
Votes
name

There are lots of wifi hotspots that are open, but require a web-based login to use. Hotels, coffeeshops, workplaces. For password-protected wifi, it's easy to set up Android phones to remember the login and password. But I'd like to be able to use my workplace's open wifi with web-based password on a regular basis, without having to manually type stuff in. It should just automatically connect to the Wifi router, go to http://1.1.1.1 or whatever, type in my password, and then everything else should just work. Is this possible?

(HTC Evo running Android 2.2, fwiw...)

 

You can take a look at this question, you'll have to customize it for your needs, namely changing the field names.

Also, I don't know if this applies to your situation, but storing sensitive passwords is "tricky" at best, maybe consider simply opening the browser and letting the user (or the browser if it's setup to save credentials) take care of entering the password.

Edit: The example from that question:

mWebView.loadUrl(url);
mWebView.getSettings().setJavaScriptEnabled(true);
mWebView.setWebViewClient(new WebViewClient() {
public void onPageFinished(WebView view, String url) {
    String user="u";
    String pwd="p";
    view.loadUrl("javascript:document.getElementById('nameofyourusernamefield').value = '"+user+"';document.getElementById('nameofyourpasswordfield').value='"+pwd+"';");
}

});

  • 0
Reply Report
  1. On the system tray, click on the Wireless icon.
  2. Select your Guest network.
  3. Click the Connect button.
  4. Select the browser you wish to use, then click OK.
  5. You will be directed to the Guest Access login page.
  6. On the system tray, click on the Wireless icon.
  7. Select your Guest network.
  8. Click the Connect button.
  • 0
Reply Report

I currently work in an environment that has used Linux for more than a decade. Everybody in the office uses different distros on their desktops as well as the servers. As such, the choices of distribution tend to revolve around a number of things in no particular order:

  1. History - Obviously systems like RedHat and Debian have been around for a long time. As such, the adage "if it ain't broke, don't fix it" can be used for these. Upgrading becomes easier if the software is supported well on a distro.
  2. Familiarity - Similar to History, however we all have our favourites. I cut my teeth on Debian, and migrated to Ubuntu (a hard decision at the time because I tend to commit to a community). Conversely, it's a pain to have to remember how to do things on a dozen different distros (not to mention the scratch-built ones).
  3. Support - I migrated to Ubuntu mainly because I appreciated what they were doing as far as offering paid support. That was a selling point if ever a client had a concern about running a system long-term. Similar to RedHat's approach (but RPM hell was going on at the time). We have a number of RedHat servers for this reason also.
  4. Dependencies - Some softwares are easier to use on some distros simply because the dependent packages are more easily obtainable or buildable. As example of this would be oVirt on RedHat. There are no packages for some softwares on some distros. And you could compile it, but why would you if the package was right there on another distro?
  5. Granularity - Distros like Gentoo offer finer control over versioning and software-switch granularity. Other distros have "pinning" in various forms, but that's still not as controllable or reliable.
  6. Binding - While it's possible to compile from source on most distros, some distros are better at it than others. This can have an effect, say, if your project patches existing libraries for extended functionality.
  7. Prettiness - Some distros are just better-looking. Every geek knows it's just fluff (and you could probably get away with doing it as a web app these days) but some clients are wowed by this stuff, and we all know it.
  8. Stability - Some distros stream "stable" versions of software as opposed to "testing", "experimental", etc. This can mean alot if you know that the version you're building on will eventually reach a consensus on stability. You may develop on "experimental" knowing that by the time your project is finished it will have reached "stable" and be good to rely on.
  9. Package management - If you're developing something on a daily basis, and it's going to go out to 1000s of machines in one hit, then you probably want something that makes it easy to build, maintain, and track packages across those systems.
  10. Consistency - This is more an argument for the same distro. Less mistakes get made (and less errors in security) when people can focus on one distro as opposed to several.
  11. Predictable release schedule - If you want to be sure that your software stays supported, planned upgrades offer a certain type of stability.
  12. Security - Some distros have active security teams whose job it is to respond immediately to genuine security risks in any approved package.

Those are just a few things that come off the top of my head regarding reasons why each system was chosen. I don't see any one guiding light or preference of one distro over another in this decision. Diversity and choice can be great and offer you some really good options to get a project started quickly, but it's also the noose that can hang you. Make sure you think ahead of what you're going to need. Plan what the system's needs are as well as when the system is going to be upgraded or retired. Don't assume you'll always be the one maintaining it.

  • 0
Reply Report

The best you can do is set it up to auto-connect to the network and then manually open a browser when you're in range. Save the username and password in the browser. That gets it down to 2 clicks (er... touches). Make sure Remember Passwords is on the the browser's settings.

There are some apps that claim to do what you want but I've never used them. Here is a list.

  • 0
Reply Report