mirror of
https://github.com/jhd3197/ServerKit.git
synced 2026-11-09 13:35:12 +09:00
Juan DenisandClaude Opus 5
fc000a3b97
Plan 73 item 5. The Domains SSL modal asked for a contact email on every single certificate, and the backend hard-required one per call. The app-detail Settings tab did remember it -- in localStorage, so the memory was per browser and invisible to the other surface. The two never agreed, and neither could help the paths with no form at all: domain attach passed `admin@<host>` when it had nothing else, an address that usually does not exist, which is where every expiry notice for those certificates went to die. There is now a single panel-wide ACME contact in system settings. get_acme_contact() resolves an explicit address first and falls back to the stored one; remember_acme_contact() writes it back whenever a request carries an explicit address. Both are best-effort on the settings side by design: a settings failure must not break issuance, and failing to remember an address must not turn a successful certificate into an error. An empty input never clears a stored contact, since the automatic paths pass whatever they were given and that is frequently nothing. Wired into every issuance entry point -- the domain SSL enable route, the generic certificate route, and domain attach, which now consults the stored contact before falling back to the admin@<host> guess. The address is only remembered after issuance actually succeeds; remembering one Let's Encrypt rejected would be worse than remembering none. Prefill needed its own endpoint. The settings routes are all admin-gated, but issuing a certificate for an app you can edit is not an admin action, so GET /ssl/acme-contact is jwt_required only -- it returns an address the operator chose for notices, not a credential. The Domains modal and the Settings tab both prefill from it, and the Settings tab keeps its localStorage seed so a browser that already has the value shows it without a flash. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
React Dashboard Template
A modern React dashboard application boilerplate built with Vite, featuring routing, charts, and a sidebar layout for building data-driven web interfaces.
Features
- React 18 with functional components and hooks
- Vite for fast development and building
- React Router for client-side routing
- Recharts for data visualization
- Lucide React for icons
- ESLint for code linting
- Responsive sidebar layout
- Dashboard page with sample components
Getting Started
Prerequisites
- Node.js 16+ and npm
Installation
- Clone or download this template
- Install dependencies:
npm install
Development
Start the development server:
npm run dev
The app will be available at http://localhost:41921.
Building for Production
Build the app for deployment:
npm run build
The output will be in the dist/ directory.
Preview Production Build
npm run preview
Project Structure
src/
├── App.jsx # Main app with routing
├── main.jsx # Entry point
├── index.css # Global styles
├── components/
│ └── Sidebar.jsx # Navigation sidebar
├── layouts/
│ └── DashboardLayout.jsx # Main layout wrapper
└── pages/
└── Dashboard.jsx # Main dashboard page
Customization
- Modify components in
src/components/ - Add new pages in
src/pages/ - Update routes in
App.jsx - Customize styles in
index.cssor component files
Environment Variables
Create a .env file in the root for environment variables:
VITE_API_URL=https://api.example.com
Access them in code via import.meta.env.VITE_API_URL.
Contributing
See the documentation files for AI agent permissions and guidelines.