Get ui tests passing

[cesine]

• publish prototypedev to support using localhost by default if running on localhost and troubleshoot corpus.html not loading
• the csp has quotes in it

- [ ] the local app is still not working well with the couchdb in its container (it works in ci) https://github.com/FieldDB/FieldDB/pull/2193

Manual testing

0. turn on the docker container locally then turn off the auth app

0. turn on the app in a terminal 1. register a new user 2. login on https://localhost:6984/_session

4. https://localhost:6984/prototypedev/_design/prototype/user.html loads but the corpus list is missing because it is fetching from prod by default and not localhost

6. corpus is fetching https://localhost:6984/default/test1768871342172
   and showing a spinner

[gemini-code-assist]

Summary of Changes

Hello @cesine, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses critical configuration issues that were preventing UI tests from passing and hindering local development workflows. The main change involves modifying the Content Security Policy to explicitly allow script execution from the local CouchDB instance. This adjustment is essential for resolving problems where local applications fail to load or interact correctly with the backend, thereby establishing a functional local development environment and ensuring the reliability of UI tests.

Highlights

• Content Security Policy (CSP) Adjustment: The Content Security Policy in etc/local.ini has been updated to include https://localhost:6984 in the script-src directive. This change is crucial for allowing scripts from the local CouchDB instance to execute, resolving issues where local applications were failing to load or interact correctly.
• Enabling UI Test Passage and Local Development: The primary objective of this pull request is to address underlying configuration problems that prevent UI tests from passing and hinder a functional local development setup. By fixing the CSP, the PR aims to ensure that local environments can properly load and interact with the backend.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the Content Security Policy (CSP) in etc/local.ini to allow scripts from localhost:6984, which is a necessary step for local development and testing. My review focuses on ensuring the CSP is correctly formatted and secure. I've pointed out that the quotes around the CSP value should be removed, as noted in a new comment, to make the policy effective. Additionally, I've raised a concern about the use of 'unsafe-eval' and 'unsafe-inline', which are insecure and should be avoided if possible, even in a development environment.

[gemini-code-assist]

This comment correctly notes that the quotes in the attachments_header_value should be removed, but they are still present on the next line. The quotes will likely cause the Content Security Policy to be invalid. Please remove the quotes from the value, and you can remove this comment as well.

attachments_header_value = child-src 'self' data: blob:; default-src 'self'; connect-src 'self' https://corpusdev.example.com https://localhost:3183 https://www.google-analytics.com; img-src 'self' data: https://secure.gravatar.com; font-src 'self' https://themes.googleusercontent.com; script-src 'self' https://localhost:6984 'unsafe-eval' https://www.google-analytics.com; style-src 'self' 'unsafe-inline';

[gemini-code-assist]

The Content Security Policy includes 'unsafe-eval' and 'unsafe-inline'. These directives significantly weaken the security of your application and should be avoided as they create openings for Cross-Site Scripting (XSS) attacks.

• 'unsafe-inline' allows inline <script> and <style> tags, as well as inline event handlers (e.g., onclick). Consider moving all scripts and styles to external files.
• 'unsafe-eval' allows the use of eval() and similar functions. It's best to refactor any code that relies on these.

Even for a local development configuration, it's a security best practice to have a strict CSP. This helps catch potential issues before they reach production.