Adds Posthog support to the frontend. #693
Conversation
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 9430286 | Triggered | Generic Password | 0218f76 | docker-compose.yml | View secret |
| 9430286 | Triggered | Generic Password | 5ac97af | docker-compose.yml | View secret |
| 9430286 | Triggered | Generic Password | 392893b | docker-compose.yml | View secret |
| 9430286 | Triggered | Generic Password | b838810 | docker-compose.yml | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secrets safely. Learn here the best practices.
- Revoke and rotate these secrets.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Our GitHub checks need improvements? Share your feedbacks!
jkachel
force-pushed
the
jkachel/posthog-frontend-support
branch
from
0ff97b1 to
3380595
Compare
jkachel
force-pushed
the
jkachel/posthog-frontend-support
branch
from
a2b3247 to
6e2903d
Compare
jkachel
added
Needs Review
| const resources = factory.resources({ count: 4 }) | ||
| setMockResponse.get(urls.learningResources.list(), resources) |
There was a problem hiding this comment.
renderTestApp renders the whole app, which makes some API calls, you you had to mock, which is a pain.
I would recommend using renderWithProviders for this:
renderWithProviders(<div data-testid="some-children" />)then you won't need to mock the API calls. (renderTestApp uses renderWithProviders internally)
for more information, see https://pre-commit.ci
- Update the docker-compose to make the external Postgres port configurable in the .env - Update the .env.example - Fixed a bug in get_all_feature_flags - Exposed the feature flag list view, made it work
…ble cache This should mean the cache is preferred for PostHog feature flags. This doesn't include code to update the cache just yet.
for more information, see https://pre-commit.ci
well that was dumb
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
jkachel
force-pushed
the
jkachel/posthog-frontend-support
branch
from
c2011e0 to
4c987a7
Compare
main/views.py
Outdated
| "posthog": { | ||
| "api_key": settings.POSTHOG_PROJECT_API_KEY, | ||
| "enabled": settings.POSTHOG_ENABLED, | ||
| "timeout": settings.POSTHOG_TIMEOUT_MS, | ||
| "bootstrap_flags": all_flags, | ||
| }, |
There was a problem hiding this comment.
Recently @shanbady did some work to remove environment settings from the django view. Instead, any env variables that the frontend needs can be injected via the webpack build: https://github.com/mitodl/mit-open/blob/87fa1ad3e93905a391ad7cbb18c09fb1ed771904/frontends/mit-open/webpack.config.js#L87-L99
This is part of some work to make the HTML static so that it can be served by a CDN.
There was a problem hiding this comment.
(user is still injected via django, Jon is doing some work to stop that and get user info via an api)
There was a problem hiding this comment.
I changed this to not depend on Django injection at all - however this does change how the flag bootstrapping works; instead of being able to pull from the durable cache present there, it'll use the settings in the .env file instead. The default is for it to look at items that begin with FEATURE_ and this is configurable by setting MITOPEN_FEATURES_PREFIX (which will also change it in the Django app). It doesn't do any processing of the feature flag name other than stripping the prefix so it's up to us to make sure these agree between the app and the PostHog settings. (The code does normalize a Python "True" into a JavaScript true - other values are left as-is.)
There was a problem hiding this comment.
Could we remove the posthog HTML injection all together now?
With this, the frontend won't pull feature flag data from the Django cache as it won't have access to that anymore. You can, however, set the same feature flags in the .env file as "FEATURE_<flag name>". Boolean flags set using Python convention (i.e. True) will be set to JavaScript true; anything else will be stringified.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
main/views.py
Outdated
| "posthog": { | ||
| "api_key": settings.POSTHOG_PROJECT_API_KEY, | ||
| "enabled": settings.POSTHOG_ENABLED, | ||
| "timeout": settings.POSTHOG_TIMEOUT_MS, | ||
| "bootstrap_flags": all_flags, | ||
| }, |
There was a problem hiding this comment.
Could we remove the posthog HTML injection all together now?
| <PostHogProvider apiKey={phSettings.api_key} options={phOptions}> | ||
| {interiorElements} | ||
| </PostHogProvider> |
There was a problem hiding this comment.
Would be nice if PostHog's provider had an enabled prop that made it a no-op of enabled=false.
What are the relevant tickets?
Closes #589
Description (What does it do?)
Adds PostHog integration to the frontend with these settings:
.envfile.envfile.The PostHog provider is situated near the top of the provider stack for the app - right after
StrictMode- which should allow for feature flag checking and event collection for all parts of the app.How can this be tested?
Automated tests should pass.
Test setup of the PostHog provider: If the
POSTHOG_ENABLEDflag is set toTrue, you should see thePostHogProviderin the Components tree in the React dev tools. You should not see it if the flag is set to False.Test pre-loading of flags: With the provider enabled, you should be able to see the flags that the Django app knows about pre-loaded into the provider by navigating to the provider component in React dev tools and looking through the options. The preloading will use the currently logged-in user's username as the unique user ID for retrieving flags. Doing it this way should also load the flags from cache (see PR #682) if there's a cached value.