Kupiki-Hotspot-Script icon indicating copy to clipboard operation
Kupiki-Hotspot-Script copied to clipboard

Redirection on Android with Chrome

Open desevensa opened this issue 5 years ago • 8 comments

Actual behavior

If I ignore the login splash and then I open Chrome on Android. Doesn't matters if I type any URL or search, Chrome stands loading until I get Timeout error

Expected behavior

Instant redirect to login splash, how fix it?.

Additional comments

  • It I type http://192.168.10.1 the splash screen (On Chrome for Android) loads as expected.
  • If I open Firefox for Android, with URLs redirects to splash screen, but with direct search it gets loading until Timeout error.
  • With Linux on PC it looks to work as expected.
  • IOS, unknown

desevensa avatar Feb 03 '19 20:02 desevensa

I guess that's because your are using https request for the search. By default, coova is redirecting only http Check here if it improves (https://uz.sns.it/~enrico/site/posts/networking/coova%20chilli/enabling-https-redirect-in-coova-chilli.html) with known consequences

pihomeserver avatar Feb 04 '19 13:02 pihomeserver

Unfortunately it was really clear, anyway I'm thinking about how to solve this and I have 2 ideas but both, I think, are a nightmare.

  1. Find a way to force every https to redirect to http address only to unauthenticated clients. Something like sslstrip. It is challenging because I have no clue about how use it and implement it only for non authenticated clients.
  2. Get certificates from a CA but it means take out the splash screen to an external address, looks easier but how to fix the configuration.json file to point exactly to the raspberry in order to get a successful login?

desevensa avatar Feb 04 '19 17:02 desevensa

You will not get a CA certificate for a home server without a domain name etc. Why do you want to modify the configuration.json file ? Is it not better to update coova configuration to link to external host even i am pretty sure its not safe at all

pihomeserver avatar Feb 05 '19 21:02 pihomeserver

Why do you want to modify the configuration.json file ?

I tried coping all the folder /usr/share/nginx/portal to an external server in order to test and the json file has set the chillicontroller to a local IP (192.168.10.1). There, in external server, the hompage gets an error because it's searching in the wrong place (Error message: The last contact with the Controller (192.168.10.1:3990) failed. Error : JSON request timed out (or reply is not valid)). But it was just an idea.

i am pretty sure its not safe at all

You're right, I was just thinking in options.

Is it not better to update coova configuration to link to external host

Unfortunately Im a begginer with coovachilli and i've been sometimes stucked reading documentation by language issues (Not my native language), any tip will be helpful

desevensa avatar Feb 06 '19 01:02 desevensa

192.168.x.x is a private LAN so not available from Internet.

You can check if you can have a SSL certificate on a DynDNS or NOIP system ? It sounds to be a little bit complex problem

pihomeserver avatar Feb 06 '19 07:02 pihomeserver

I'm interested in this as well... but even other hotspot not using coovachilli has this behavior...

reigelgallarde avatar Feb 06 '19 08:02 reigelgallarde

I gess it is solved, could be work in this way:

  1. Own a webpage with ssl: **https://www.**whateveritbe.xyz mandatory https and www
  2. Set coova configuration to uamhomepage=https://www.whateveritbe.xyz and uamdnsallow=.whateveritbe.xyz
  3. The code into whateveritbe.xyz must have a redirection to http://192.168.10.1. I still have not try it (to close the topic) but it should work.

desevensa avatar Feb 11 '19 21:02 desevensa

I gess it is solved, could be work in this way:

1. Own a webpage with ssl: **https://www.**whateveritbe.xyz mandatory https and www

2. Set coova configuration to _uamhomepage=https://www.whateveritbe.xyz_ and _uamdnsallow=.whateveritbe.xyz_

3. The code into whateveritbe.xyz must have a redirection to **http://192.168.10.1**.
   I still have not try it (to close the topic) but it should work.

It works, i just said something wrong with that previous comment, then i will make some sort of errata for point number 2. 2. is not uamdnsallow, it's HS_UAMDOMAINS the value to set. The value HS_UAMHOMEPAGE needs to be set to the url's page with ssl. Also i commented the value HS_UAMALLOW, I'm not sure what does it do but portal captive looks work fine (is it OK?).

desevensa avatar Feb 19 '19 17:02 desevensa