Server

Server

Please note that this functionality is still highly experimental.

Security

PLEASE NOTE: Using this functionality as of now is insecure as it requires wide open CORS. An attacker could potentially use a page from a website he controls to exfiltrate the report data, even if it is not exposed.

Use case

The traditional way use of Scout is to run the tool which will generate an local HTML report to be viewed. The problem with this approach is that when dealing with huge amount of data (over 400mb), the browser cannot load it all into RAM at once. In these cases, what we can do is serve the report result over a web server.

Current limitations

Size

The current hard size limit for this is about 2Gb, as the underlying library to access the SQLite database doesn't support saving nested dictionaries yet and SQLite can only support up to 2GB of data in a single data blob. Note that these limits are still theoratical and haven't been tested.

Browser support

For now, everything was tested when using Mozilla Firefox, but is known to not be working for Google Chrome as the browser denies CORS requests coming from file:// handler. This can eventually be fixed by serving the entire report over HTTP with the server.
In the meantime, it is possible to bypass this restriction by running Google Chrome with the --allow-file-access-from-files flag.

Usage

To generate the report for azure, use a command simillar to this: ./Scout.py azure -c --result-format sqlite To server the report, use the following command: ./Scout.py azure -c --serve This will serve the report on 127.0.0.1:8000. Not that, for now, You still need to connect to the cloud provider to connect, but this can be fixed with a bit of refactoring.
To serve a specific report: ./Scout.py azure -c --serve reportname To serve on a specific socket, you can use the following options: ./Scout.py azure -c --serve --host 0.0.0.0 --port 80 Please note that this can only be used for testing the server for now, as the static report doesn't allow this for now.

What's left

• Make the --serve argument a subparser. This will require some changes as, right now, we need the provider object to find the filenames, which requires to log in.
• Serve the html report too on the server. This is cleaner, would allow chrome to work flawlessly and would simplify a lot the host/port configuration.
• Fix SQLiteDict so it supports nested dictionnaries, which would allow reports to go up to 140TB in size.
• Test this with heavy load to make sure it works in the intended scenario.