Date: 2026-08-09
Update: 2026-08-11
Old iOS versions have trouble displaying the login screen for confirming usage conditions of the network. In my case, the browser would not render the page due to new Javascript features. I could accept the conditions via a small browser bookmarklet:
First, by placing these 2 links on the device bookmarks – on iOS this means painstakingly holding and dragging the link to the top bookmark icon, waiting for the sidebar to open and dragging it inside the bookmarks. Alternatively, you can bookmark a random address, edit after saving and replace the URL by pasting the script source.
Bookmarklet: WifiOnICE Logon
Bookmarklet: WifiOnICE Logoff
After logging into WifiOnICE, the login dialog is available in the local network via https://login.wifionice.de/ 1.
Once the URL is opened – even in a broken state – opening the bookmarks accepts the usage declaration or logs off. How? the API endpoint expects a browser-certified script call from the same domain, see explanation.
Test the connection on a webpage.
Both bookmarklets send a CRSF call from the browser – the only difference is the logon/logoff API path. The script is a proof-of-concept and could be optimized in many ways, see below.
Logon:
javascript: var request = new XMLHttpRequest(); request.open("POST", "/cna/logon"); request.withCredentials = true; request.setRequestHeader("x-csrf-token", "fetch"); request.setRequestHeader("Accept", "application/json"); request.setRequestHeader("Content-Type", "application/json; charset=utf-8"); request.send();
Logoff:
javascript: var request = new XMLHttpRequest(); request.open("POST", "/cna/logoff"); request.withCredentials = true; request.setRequestHeader("x-csrf-token", "fetch"); request.setRequestHeader("Accept", "application/json"); request.setRequestHeader("Content-Type", "application/json; charset=utf-8"); request.send();
On connecting to the network, https//login.wifionice.de opens in a system browser window and redirects to /cna/?r= followed by a random number.
Luckily, the script is not hard to read:
Depending on the status, a login/logout element is rendered.
Clicking the element triggers a call to an analytics subdomain and calls /cna/logon via XHR.
The callback reloads the API route: in a logged on state it redirects to https://iceportal.de, otherwise the call is attempted again – pretty elegant, I suppose.
Calling the login page while being logged on renders a different button – pointing to the logoff route and redirecting to the login page.
While you can't imitate this CRSF call with – say, a curl command due to no token being supplied on the page, the ingenuity of the X-CRSF header means the browser signs itself when called on the correct CORS context. Via Barry Pollard:
“Any requests will send both the header (set by Javascript) and the cookie (set by the browser as a standard HTTP header) and then the server can check that value in the X-CSRF-TOKEN header matches the value in the cookie header. The idea being that only JavaScript run on the same domain would have access to the cookie, so JavaScript from another domain couldn't set this header to the right value (assuming the page is not vulnerable to XSS that would give access to this cookie). Even fake links (e.g. in a phishing email) would not work either, as even though they would appear to come from the right domain, only the cookie will be set but not X-CSRF-TOKEN header.”
— Stack Overflow, 2016
If you have any feedback on other devices, I'd be happy to hear about it.
The scripts could be optimized by:
Content-Type and Accept are neededTesting older iOS browsers is possible when Safari is paired to tabs of connected iOS devices via developer tools. You can debug layout styles and console scripts of the legacy system on a desktop machine.
When debugging network calls, the “don't empty logs” option prevents the network tab from clearing connections on new URLs. Additionaly, I use a low bandwith throttle to easer read the order of calls – a cheap alternative to full profile logs.
Info via official DB wifi docs. ↩