Get Local storage data set by a web-server using python

Question

I am testing my website to flood its analytic api calls. As my site uses local storage to identify a client, I need to access local storage.

I can access cookies in python using this code:

import cookielib
import urllib2

cookies = cookielib.LWPCookieJar()
handlers = [
    urllib2.HTTPHandler(),
    urllib2.HTTPSHandler(),
    urllib2.HTTPCookieProcessor(cookies)
    ]
opener = urllib2.build_opener(*handlers)

def fetch(uri):
    req = urllib2.Request(uri)
    return opener.open(req)

def dump():
    for cookie in cookies:
        print cookie.name, cookie.value

uri = 'http://localhost:3000'
res = fetch(uri)
dump()

res = fetch(uri)
dump()

# save cookies to disk. you can load them with cookies.load() as well.
cookies.save('mycookies.txt')

How do I access Local storage data in python?

Answer 1

Local storage is specific to browser.

Local Storage is a way to store persistent data using JavaScript. It should be used only with HTML5 compatible web browser. Local storage - according to stack overflow tag definition

To access Local storage in python, a HTML5 compatible browser's python API is required.

Answer 2

costales came up with a solution for Chrome, here:

How to read/modify a local file of HTML5 Local Storage from Python?

It makes use of the fact that Chrome and Opera use "SQLite format 3" for Web Storage (a/k/a Local Storage, or DOM Storage). Under Windows 10 Chrome currently keeps its Web Storage files in this folder:

"%LOCALAPPDATA%\Google\Chrome\User Data\Default\Local Storage\"

Opera should be similar. (Old Opera used XML files, but recent versions of Opera are basically forks of Chrome / Chromium.)

Firefox is similar, except that it appears that Firefox uses one great big SQLite database for all Web Storage for all web pages; see Hugh Lee's and Kevin Hakanson's answers here:

Where does Firefox store javascript/HTML localStorage?

costales' solution is to simply import sqlite3 and then read Chrome's local storage files. Pretty sweet!

Answer 3

I guess the main idea behind your question is how to communicate between a Chrome extension and a native app. There are several ways to do that, depending on your specific requirements and constraints. Here are some of the most common options:

1. Native messaging: This is a built-in feature in Chrome that allows you to send messages between the extension and a native app using a JSON-based protocol. The native app needs to register a manifest file with Chrome, and the extension needs to send messages to a specified host and port. Native messaging can be secure and reliable, but it requires some setup and development effort.

2. WebSocket: You can use a WebSocket to establish a bi-directional connection between the extension and the native app. The WebSocket can be opened from either side, and messages can be sent and received in real-time. WebSocket communication can be fast and efficient, but it requires more setup and may not be as secure as native messaging.

3. HTTP REST API: You can expose a REST API from the native app, and the extension can make HTTP requests to this API to exchange data. This approach is widely used and can be easy to implement, but it may not be as fast or efficient as native messaging or WebSocket.

4. Shared memory: You can create a shared memory buffer that both the extension and the native app can access, and use this buffer to exchange data. This approach can be very fast and efficient, but it requires careful management of the shared memory to avoid synchronization issues and security vulnerabilities.

Ultimately, the best way to communicate between a Chrome extension and a native app depends on your specific requirements. You should consider factors such as performance, security, ease of implementation, and compatibility with existing systems when choosing a communication method.

I am not a big fan of (2) and (4) so we are left with (1) and (3), the advantage of (3) is the native app need not be on the same host. Advantage of (1) is I guess is it's what google officially recommends and hence puts in all effort to make it full proof and secure. So if you are doing it for the first time go with (1). But in long run if you want a simpler and more straightforward approach, HTTP REST API might win on the ease of implementation parameter.