a user experience so secure and seamless, your boss won't even know you're working at the pool in Hawaii
Remote Debugging Chrome & SameSite cookies with Chrome DevTools
Get link
Facebook
Twitter
Pinterest
Email
Other Apps
When developing and delivering use-cases for Android or iOS devices, remotely debugging and inspecting how content is rendered in Google Chrome can be challenging. In the last few years, Chrome introduced a very useful feature that allows remote debugging. This functionality became infinitely useful when working on a use case that leverages cookies in a third-party context. In this blog post, we'll cover why cookies can be a headache (for all platforms), and how Chrome DevTools can be used to isolate issues on mobile devices.
Requirements:
Android OS with Developer Options enabled
USB Debugging enabled
USB-C Cable
To connect Android device to macOS / Windows device
Google Chrome (mobile)
Google Chrome (macOS / Windows device)
Context:
A use case I am involved in hosts content internally on a private cloud using VMware Tanzu (formerly Pivotal Cloud Foundry). This private cloud has its own unique domain. So while the user might be authenticating and viewing content on www.myLearning.WS1inHawaii.com, the video content displayed in an iFrame would be streaming from a different domain, like www.cdn.myHawaiiCloud.net.
Sounds neat, right? We save on public cloud data egress costs by hosting the video content on our private cloud. Then to provide the responsive web-site for users, we host it on a provider that is more performant across all geographies - like CloudFlare or Amazon Web Services.
The Problem
Each cookie issued by a service has a key/value pair that identifies how the cookie can be used. There are first party cookies, and third party cookies. In 2020, Google and Apple (and all browsers based on Chromium and Webkit) introduced a secure by default model for cookies used in a 3rd party context. This secure by default model protects 3rd party cookies from external access unless otherwise specified in the 'SameSite' key/value pair.
What this meant for the business is content in an iFrame would suddenly not render. On Chrome version 80 and above, all cookies without SameSite attributes will be treated as if they have 'SameSite=lax' specified. With this secure by default model, if the SameSite attribute value is set to 'lax' and is from a 3rd party, it will be blocked. When the 3rd party cookie is blocked, it will cause content from that 3rd party to not render.
In our case, the 3rd party service internally developed did not serialize cookies with the SameSite value set. This impacted iOS, macOS, Android and Windows devices, but only devices that had newer browsers.
It is important to note that we needed a permanent, secure, solution that works on all platforms. Google has settings temporarily available to exempt cookies from this new secure by default model. These settings are scheduled to be deprecated in late 2021 / 2022. Enabling these would be considered less secure, as it introduces a cross site request forgery attack vector. In addition, these settings are not available on all platforms (iOS is currently excluded). In our use case, the most secure solution will come by introducing a CNAME DNS record that points to our A record for the CDN hosted on Tanzu. The next most secure solution would be to serialize the cookie with the SameSite values specified as:
'SameSite=None; Secure'
Finally the least secure option would be to use Workspace ONE to introduce a client side fix with Chrome, which would allow cookies to be sent with all cross-site requests. Since this service was developed on a wrapper over Spring Boot (a popular Java framework), the codebase could be updated to serialize the cookies with the SameSite attribute set. This ultimately solved the issue on all platforms and browsers.
So how do you even know if something like this is impacting you, especially on a mobile device? Remote Debugging with Chrome, that's how.
Remote Debugging Chrome Mobile on Android with Chrome DevTools
On the Android device, enable Developer options
Enable USB Debugging in Developer options
Connect the Android device to your macOS / Windows host
Open Chrome on the Android device
Open Chrome on the macOS / Windows host
On the macOS / Windows host, navigate to the URL: chrome://inspect/#devices
On the macOS / Windows host, you should see something like this:
The SM-T830 device has developer options enabled, and Chrome open. On the mobile device, every Chrome tab, including Chrome custom tabs, will be displayed here.
Click inspect on the mobile site browser tab that you wish to inspect
On the mobile device, navigate to the website that fails to render content
If the web browser is newer than Chrome 80, open the Google Play store and uninstall the Chrome browser. While you cannot uninstall the browser, you can downgrade the browser to the version shipped with the device. The screenshot you see below will only display on Chrome browser versions 79 or lower.
Click the 'Console' tab in Chrome DevTools. If you see references to a cross-site resource with SameSite cookies attributes properly set; the cookies serialized by the service are not sent with the values; 'SameSite=none; Secure'
To see the cookie key/value data, click 'Network', followed by 'Cookies'. Make sure 'show filtered out request cookies' is checked, in addition to 'Has blocked cookies'
If you hover your mouse over the cookie, it will warn you about the SameSite attributes
If you open a new browser tab on the mobile device, and you wish to inspect it; you will need to close 'DevTools' and click 'Inspect' on the new tab you opened.
To highlight how Remote Debugging works, I created this short video. In this video you see how to inspect browser tabs on remote devices, and use DevTools much like you would on a non-mobile device.
The goal of this blog post is to share the value of using Chrome DevTools to inspect how content is rendered on a mobile device. Prior to DevTools supporting remote debugging, it was much more difficult to obtain this kind of data. When DevTools is combined with Fiddler and a tool to troubleshoot AuthN/AuthZ (e.g. rcFederation), you can tackle nearly any issue.
If you are interested in learning more about Remote Debugging with Chrome DevTools, or SameSite cookies - check out some of the links below.
When it comes to accessing API's and securing your digital workspace, we have options. When accessing Workspace ONE API's, we have options when securely interacting with them; like using base64 encoded credentials, or OAuth access tokens (versions 2001 and newer). In a previous blog post, we covered how to store sensitive credentials used to access Workspace ONE API's with a config.ini file. This approach works, and while ACL's can limit accounts that can read data at rest; organizations may still prefer to not store credentials in something like json or a old school ini file. Today, we'll provide you with your daily dose of uplifting imagery from Hawaii, code to retrieve credentials at runtime, store base64 encoded credentials in memory during execution, and access Workspace ONE API's with the credentials. This way, you can simply hand your code off to operations, sit by the beach, hop on a trail, and enjoy your time in Hawaii. Waimea Canyon, the G
Digital workspace solutions often require consuming other services. When doing so, you may work with things like; REST API endpoints, Webhooks, gRPC, GraphQL - the list goes on. You can interact with these in a number of ways, but one way I've come to appreciate is with Java. It has been especially helpful when I've wanted to work with libraries like Appium, Selenium, OKHttp, or the Workspace ONE UEM SDK in a workflow. With that, I thought it would be helpful to share how to work with Workspace ONE UEM API's using Java. In this blog post, we will cover; Basics of JetBrain's IntelliJ IDE, touching on Apache Maven Using Square's OkHttp library to call Workspace ONE UEM API's Why Java? Java is used by many and supported by most (Docker, Kubernetes, static code analysis tools, cloud service providers, Android, Windows, macOS, Tanzu Application Service, etc). Many languages compile to j ava
Comments
Post a Comment