-
Notifications
You must be signed in to change notification settings - Fork 3
Deploy app and configs #104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Casbin debug
discord link
Update README.md
Update README.md
Update README.md
Update README.md
Feature user service refactoring
- Add Default derive to DiscoverResponse - Fix HealthCommandReport field access (no container_name/image fields) - Fix fetch_by_project_id return type (Option, not Vec)
Add migration to grant access to discover and import endpoints: - GET /api/v1/project/:id/containers/discover - POST /api/v1/project/:id/containers/import Grants access to group_user, group_admin, and root roles.
…responses CORS headers were missing on 400 error responses because errors from JSON extractors bypassed the middleware. Moving CORS to first .wrap() position ensures it runs last in response pipeline, adding headers to all responses including errors.
…health checks The discover endpoint was only seeing containers that appeared in health check results. But health checks only return registered apps + system patterns. Now it: 1. First looks for list_containers command results (has ALL containers) 2. Falls back to health check results if no list_containers found 3. Properly parses system_containers array from health results This allows discovering unregistered containers like nginx-proxy-manager.
Updated version and build information in the README.
Removed startup banner section from README.
uwsgi (which serves user service on :4100) might not handle HTTP/2 well. Force reqwest to use HTTP/1.1 only to prevent connection resets.
uwsgi (which serves user service on :4100) might not handle HTTP/2 well. Force reqwest to use HTTP/1.1 only to prevent connection resets.
Added health checks for critical external services: - user_service: checks /plans/info/ endpoint - install_service: checks /health endpoint - Both use http1_only to match service capabilities These checks will help diagnose connectivity issues between stacker and other microservices. curl https://stacker.try.direct/api/v1/health_check to test all services.
Added timing and error logging to diagnose connection reset issues: - Log request start - Log response status and time - Log JSON parsing time and errors - Track total items parsed This will help identify if the issue is connection, timeout, or JSON parsing.
This endpoint tests if Stacker can fetch the full 3.5MB stack_view response. Usage: curl https://stacker.try.direct/test/stack_view Will help determine if issue is: - HTTP version (http1_only fix) - Response size (timeout/truncation) - Connection pooling - MCP-specific code path
The stack_view endpoint returns 3.5MB and may have connection reuse issues. - Create dedicated client per request (no connection pooling) - 30 second timeout for large response - 10 second connect timeout - http1_only to match uwsgi capabilities - pool_max_idle_per_host(0) to prevent stale connection reuse
… connections Root cause: When /applications returns 404, the HTTP connection was pooled. The subsequent call to /stack_view tried to reuse the pooled connection, but uwsgi had already closed it, causing 'Connection reset by peer' error. Solution: Add pool_max_idle_per_host(0) to the main http_client builder.
…figs conflict resolved httpv1
- Config files now write to {base}/{app_code}/{file_name} instead of
{base}/{app_code}/config/{file_name}
- Aligns with docker-compose volume mounts (e.g. telegraf.conf at
/home/trydirect/telegraf/telegraf.conf, not .../config/telegraf.conf)
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 24149610 | Triggered | Bearer Token | bd423f5 | src/connectors/admin_service/jwt.rs | View secret |
| 25120004 | Triggered | Hashicorp Vault Token | 1f483ee | config-to-validate.yaml | View secret |
| 9658888 | Triggered | Generic Password | 0a5afab | config-to-validate.yaml | View secret |
| 26598182 | Triggered | influxdb_token | 16b5a2a | src/project_app/tests.rs | View secret |
| 25120005 | Triggered | Generic High Entropy Secret | 1f483ee | config-to-validate.yaml | View secret |
| 25120006 | Triggered | Generic High Entropy Secret | 0a5afab | test_agent_report.sh | 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.
No description provided.