LOGO! 0BA8 Webserver: Resolving Keep Me Logged In Login Failure

1. Problem Description and Field Symptoms

The Siemens LOGO! 0BA8 (LOGO! 8 generation) base module exposes an integrated Ethernet webserver that allows remote access to the controller's status, I/O, and four virtual function buttons (F1–F4). The webserver is implemented as a small HTTP service inside the LOGO! firmware and is normally accessed by navigating to http://<ip-address> from any modern browser on a PC, tablet, or smartphone.

On sites where the LOGO! 0BA8 is used as a low-cost HMI gateway (e.g. for pump control, lighting, irrigation, small HVAC, gate automation), field operators frequently report a recurring login problem. The symptoms observed in production environments are:

1. User navigates to the LOGO! webserver login page, enters Web User with a blank password (default credential set), and ticks the "Keep me logged in" / "Keep me signed in" checkbox.
2. Login succeeds. The main page with the four F-buttons loads and remains functional for the duration of the open browser tab.
3. The moment the tab is closed, the screen times out, the device sleeps, or the operator reopens the page after a short interval, the LOGO! prompts for credentials again. The persistent cookie is gone.
4. On cellular (mobile) networks the problem is amplified because the login page itself takes several seconds to render. Operators describe the workflow as: "wait for the login page to load, press Login, wait for the home page to load" – a complete round trip for what should be a single button press of F1, F2, F3, or F4.

2. LOGO! 0BA8 Webserver Authentication Model

To diagnose the "Keep me logged in" failure correctly, the engineer must understand how the LOGO! 0BA8 implements authentication. The webserver is documented in the LOGO! 0BA8 system manual (Siemens entry ID 109751040) and is functionally identical across the LOGO! 8.x generation (0BA8, 0BA8 ES02, 0BA8 FS04, 0BA8 FS05).

2.1 User Accounts

The LOGO! 0BA8 webserver supports up to eight user accounts. Two are reserved by default:

Operators who only need to push F1–F4 should use the Web User account. The empty password is a factory default and must be changed (or the account disabled) in production environments because the webserver is unauthenticated against anyone who can route to the LOGO! IP address.

2.2 Session Lifecycle

After successful HTTP POST of the login form, the LOGO! 0BA8 webserver issues a session identifier as a Set-Cookie HTTP header. The browser stores this cookie. While the browser keeps the cookie, the next request is accepted as authenticated. When the cookie expires or is removed, the server returns the login page again.

The "Keep me logged in" checkbox instructs the LOGO! firmware to set a longer-lived persistent cookie (typically a HttpOnly cookie) instead of a session-only cookie that would be lost when the browser closes.

2.3 Why the Checkbox Exists at All

Browsers distinguish between:

• Session cookies – no Expires or Max-Age attribute; deleted on tab/browser close.
• Persistent cookies – carry an Expires or Max-Age attribute; retained across browser restarts until expiry.

The LOGO! "Keep me logged in" flag is the firmware's instruction to downgrade a session cookie to a persistent cookie with an extended lifetime (typically 30 days in current firmware revisions).

3. Root Cause Analysis: Why "Keep Me Logged In" Fails on LOGO! 0BA8

The reported behavior — checkbox ticked, cookie still lost within seconds — has a small set of recurring root causes. Each is verifiable on-site in under five minutes.

3.1 Browser-Side Cookie Rejection (most common)

If the browser is configured to block third-party cookies, to clear cookies on every close, or to operate in InPrivate / Incognito / Private mode, the persistent cookie is rejected or erased immediately. The LOGO! 0BA8 webserver does not run in HTTPS by default, so the cookie is also subject to the secure-cookie policy of the browser profile.

Mobile browsers are particularly aggressive:

• iOS Safari blocks third-party cookies and has Intelligent Tracking Prevention that can drop cookies on cross-origin redirects.
• Chrome on Android (mobile data) can throttle background tabs and clear cookies after 7 days of inactivity under default settings.
• Samsung Internet and other vendor browsers may block cookies on HTTP origins by default.

3.2 HTTP-Only Cookie Behavior

Because the LOGO! 0BA8 webserver serves the login page over plain HTTP (port 80, no TLS), the cookie set by the Set-Cookie header is a non-secure first-party cookie. Several mobile browsers partition or block such cookies. The "Keep me logged in" flag does not change the cookie's Secure attribute on a 0BA8 because the service is not HTTPS.

3.3 Firmware-Specific Cookie Lifetime

Different 0BA8 firmware revisions implement cookie lifetime differently. The operator-visible behavior (login again after page close) can be caused by firmware writing a very short Max-Age even when the checkbox is ticked. Review the firmware version installed against Siemens Knowledge Base entries for the issue.

3.4 Cellular / Carrier HTTP Header Injection

Some mobile carriers (and corporate HTTP proxies) inject headers, strip Set-Cookie, or rewrite the response body for compression (Opera Turbo, Skyfire, carrier middleboxes). This silently removes the persistent cookie. The login page renders (text is not stripped), but the session is never established or is immediately invalidated by a header rewrite.

3.5 Operator-Triggered Logout

The LOGO! webserver has a logout button. Operators that habitually hit "Logout" between actions will obviously need to re-authenticate. Confirm the operator workflow before assuming a software fault.

3.6 Configuration-Triggered Auto-Logout

In LOGO!Soft Comfort, the program can be configured to send the user back to the login page on a custom condition (e.g. an inactivity timer in the ladder/FBD logic that drives a flag in the webserver). If the LOGO! program intentionally forces logout, no checkbox will override it. This is a rare but possible cause.

4. Browser-Side Diagnostic Procedure

Work through the following checks in order. Each takes under a minute on the operator's device.

1. Open a desktop browser on the same network as the LOGO! 0BA8 (e.g. from a laptop tethered to the same Wi-Fi as the LOGO!) and reproduce the issue. If the desktop retains the session across a tab close, the problem is the mobile device, not the LOGO!.
2. Open Developer Tools → Application → Cookies on the LOGO!'s origin URL. Confirm that a cookie is being set at all. If the cookie list is empty after a successful login with the checkbox ticked, the LOGO! firmware is not setting the persistent cookie.
3. Inspect the Set-Cookie response header in the Network tab. Verify the presence of Expires or Max-Age. A response that only sets a session cookie (no expiry) is the cause of the "logged out immediately on close" behavior.
4. Disable all browser extensions (ad blockers, privacy badger, HTTPS Everywhere, cookie autoclear). Test login again.
5. Test with the browser in non-private mode. iOS Safari Private Mode rejects persistent cookies by design.
6. Test from a different network (Wi-Fi instead of cellular). If session persistence works on Wi-Fi, the carrier is the culprit.

5. LOGO! Firmware and Configuration Verification

5.1 Identify the Installed Firmware

After logging in to the LOGO! 0BA8 webserver, the firmware version is displayed on the home page (typically the bottom-left corner, format 0BA8.FSxx or 0BA8.ESxx). Write this down before doing anything else.

5.2 Verify User Management Configuration

Open LOGO!Soft Comfort, connect to the LOGO! online, and inspect:

• Tools → Web User List (or equivalent menu in your LOGO!Soft Comfort version). Confirm that the Web User account is enabled and that no password has been set (matching the on-site observation).
• Tools → Access Control: confirm the account is permitted to operate the F1–F4 buttons.

If the project was edited and re-downloaded by someone else, the user database is part of the project and the credentials may have been altered.

6. Mobile Network Specific Issues

6.1 Carrier Middlebox Behavior

Several mobile carriers (and in-flight Wi-Fi providers) proxy HTTP traffic. They may:

• Strip Set-Cookie headers.
• Inject their own HTML (e.g. captive portal redirect).
• Compress or rewrite the body, corrupting the JS that drives the webserver UI.

Diagnostic: load http://<logo-ip>/ over Wi-Fi (operator's hotspot from a second phone) and confirm the "Keep me logged in" works. If it does, the cellular carrier is the problem and the only fix is a different access path (see Section 8).

6.2 Browser Default Settings on Mobile

Verify on the operator's device:

Disable all of these for the LOGO! origin.

7. Step-by-Step Resolution Procedure

Apply the following steps in order. Stop at the first step that resolves the issue.

1. Verify the credential pair is correct. Default is Web User with a blank password. If a password was set in LOGO!Soft Comfort and forgotten, it must be reset by connecting to the LOGO! and clearing the password (no factory-reset is required for the web account alone).
2. Force a fresh login on a non-private desktop browser. Tick the checkbox. Close the tab. Reopen the URL within five minutes. If the user is still logged in, the LOGO! firmware is functioning correctly and the issue is the operator's mobile device.
3. Check cookies after login on the mobile device. Use the browser's site settings to view the cookies stored for the LOGO! IP. If no cookies are stored, the browser is blocking them — fix the browser settings per Section 6.2.
4. Disable all mobile network optimization (Chrome's "Lite mode", Opera's "Data savings", carrier "VPN" services). Retest.
5. Try an alternative browser on the same device. If Firefox retains the session but Chrome does not, the fix is to switch browsers on the operator's device.
6. If on a corporate network, ask the IT team whether the corporate HTTP proxy strips Set-Cookie. If yes, request a proxy bypass for the LOGO! IP, or use a mobile hotspot to bypass.
7. If the LOGO! firmware is older than 0BA8.FS05, schedule a firmware update. Document the current program, perform the update via LOGO!Soft Comfort, verify the program restarts, and retest the login.
8. As a permanent workaround, see Section 8 (Alternative Access Methods).

8. Alternative Access Methods and Workarounds

When the LOGO! webserver cookie behavior cannot be made reliable for a particular mobile browser, the engineer has four practical options.

8.1 Bookmark the Direct Control Page

The LOGO! 0BA8 webserver supports a direct deep-link to the F1–F4 control surface. By saving a bookmark to http://<ip>/<control-page> on the operator's home screen, the operator skips the home page even if re-authentication is required. Combined with the browser's auto-fill, the re-login round trip drops to a single tap.

8.2 Add a Hardware-Shortcut on the LOGO! Side

If the only F1–F4 button being pressed is, say, F1, wire the digital input that the LOGO! would set when F1 is pressed to a physical pushbutton on the cabinet. This is sometimes the correct engineering answer: the webserver was never the right HMI for a heavily-used single-button action.

8.3 Use a LOGO! TDE (Text Display)

Install the LOGO! TDE 6ED1055-4MH08-0BA0 external display in the cabinet. It does not require authentication and provides the F1–F4 buttons natively. This is the most field-proven solution when operator ergonomics matter.

8.4 Front-End the LOGO! with a Small Industrial Gateway

A small industrial gateway (Siemens IoT2050, or a low-cost ARM gateway running Node-RED) can sit between the operator's mobile browser and the LOGO! webserver. The gateway maintains a persistent authenticated session to the LOGO! and exposes a clean, mobile-friendly UI to the operator. The operator no longer talks to the LOGO! webserver directly. This converts the persistent-cookie problem from a LOGO! issue into a gateway-managed session, which is fully under the engineer's control.

9. Verification and Acceptance Testing

After applying any fix, perform the following acceptance test on the operator's primary device:

1. Open a fresh browser session (or restart the device). Navigate to http://<logo-ip>.
2. Enter Web User / blank password, tick Keep me logged in.
3. Confirm the home page with the four F-buttons is shown.
4. Press F1. Confirm the corresponding LOGO! digital output toggles. Verify by reading the LOGO! output LED or by reading the state via the webserver.
5. Close the browser tab completely (do not just switch tabs — close the tab).
6. Wait 60 seconds. Reopen the LOGO! URL.
7. Expected (pass): The home page is shown without prompting for credentials.
8. Failure mode A: Login page is shown, the user is asked to re-enter credentials. The persistent cookie was not honored. → Continue with Section 7 starting at step 3.
9. Failure mode B: Login page is shown but the password field is pre-filled (some browsers pre-fill the last used username only). This is normal browser behavior; the operator presses Login once and is in. This is acceptable for many sites.

10. Troubleshooting Matrix

11. Engineering Notes and Field-Discipline Cautions

• Security: Leaving the Web User password blank over a routable network is a published vulnerability. Any user on the same network (or on the public Internet if the LOGO! is port-forwarded) can press F1–F4. Restrict network access to the LOGO! (VLAN, firewall rule, or a router ACL) before deploying the device outside a trusted LAN.
• Network exposure: The LOGO! 0BA8 webserver is HTTP only. There is no TLS option in the firmware. Plan the network architecture accordingly — never expose port 80 of the LOGO! directly to the Internet.
• Reliability of the workaround: A bookmark to the deep-link page reduces round-trip time but does not eliminate re-authentication. For an application where F1–F4 are pressed hundreds of times per shift, the LOGO! TDE or a physical pushbutton is the only reliable HMI.
• Documentation: Record the LOGO! firmware version in the plant's asset register. Cookie behavior changes between firmware revisions; without a baseline it is impossible to determine whether a behavior is a regression.