Problem:
- app.Run() after app services are disposed
- Catch block tried to access app.Services.CreateScope()
- Result: System.ObjectDisposedException
Solution:
- Use await app.RunAsync() instead of app.Run()
- Remove Telegram error notification from catch block
- Services are disposed after app exits, so notifications must be background tasks
Impact:
✓ App startup succeeds
✓ Sitemap and RSS feed work
✓ Admin login functional
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
The request reached the end of the pipeline - critical fix.
Added root path mapping to redirect to /taxbaik/
This ensures the root endpoint is handled.
Emergency deployment to fix production 500 error.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
URGENT FIX:
The request reached the end of the pipeline without executing the endpoint
Root cause:
- UseBlazorFrameworkFiles was positioned AFTER UseRouting
- This caused WASM files to not be intercepted properly
- Result: 500 error on all requests, admin login completely broken
Solution:
Correct order (ASP.NET Core pipeline):
1. UsePathBase
2. UseResponseCompression
3. UseBlazorFrameworkFiles (WASM files) ← MUST be BEFORE UseRouting
4. UseStaticFiles (static assets)
5. UseSession
6. UseRouting ← Now in correct position
7. UseExceptionHandler
8. UseRateLimiter, UseAuthentication, UseAuthorization, UseAntiforgery
9. Map* (endpoints)
10. MapFallbackToFile (SPA fallback, LAST)
Critical: Middleware order is pipeline execution order.
UseBlazorFrameworkFiles must run BEFORE routing to intercept WASM requests.
This fixes:
✓ 500 InvalidOperationException
✓ Admin login page WASM loading
✓ All static WASM files (_framework/)
✓ Portal login page
✓ Razor Pages (Sitemap, RSS)
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Changes:
- Rss.cshtml: Fixed Razor/XML syntax by using StringBuilder
- Feed.cshtml: Alias for /feed.xml
- Both pages use RssModel (BlogService)
- robots.txt: Added feed references
Fix:
- Removed @page duplicate directive
- Used StringBuilder for proper XML generation
- Avoided Razor XML tag nesting issues
- Both /rss.xml and /feed.xml now available
URLs:
✓ https://www.taxbaik.com/taxbaik/rss.xml
✓ https://www.taxbaik.com/taxbaik/feed.xml
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
CI was still using cached deploy.yml with PublishReadyToRun=true.
Explicitly set to false for both Web and Proxy publish.
WASM projects don't support ReadyToRun optimization.
Host projects will be published without JIT compilation optimization.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Problem:
- NETSDK1095: PublishReadyToRun not supported for WASM
- WASM projects run in browser, not platform-specific runtime
- ReadyToRun optimization only applies to native binaries
Solution:
- Remove -p:PublishReadyToRun=true
- Keep -p:SelfContained=false for dependency handling
- Host project (TaxBaik.Web) will be published without ReadyToRun
- This is acceptable for ASP.NET Core deployment
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Problem:
- NETSDK1047: Assets file doesn't have target for linux-x64
- --no-restore prevented publish from reading updated project.assets.json
Solution:
- Remove --no-restore flag from publish commands
- Allow dotnet publish to refresh assets and restore if needed
- This is safe because build already restored and succeeded
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Problem:
- CI runs on Linux (ubuntu-latest)
- Local restore was Windows-only, missing linux-x64 runtime
- --no-build skipped rebuild, so publish used stale assets
Solution:
- dotnet restore -r linux-x64 (include Linux runtime)
- Remove --no-build from publish (allow rebuild if needed)
This fixes NETSDK1047 error on Linux CI.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Order is critical:
1. UseBlazorFrameworkFiles (middleware)
2. MapControllers/MapFastEndpoints (specific routes)
3. MapRazorPages (Sitemap.cshtml matches here)
4. MapFallbackToFile (catch-all last)
This prevents /taxbaik/sitemap.xml from being caught by admin fallback.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Problem:
- UseBlazorFrameworkFiles/UseStaticFiles were AFTER Map* routes
- This caused 'request reached end of pipeline' 500 error
Solution:
- Move app.Use* (middleware) BEFORE app.Map* (routing)
- Blazor framework files now properly served at /admin/_framework
- Portal SPA fallback working correctly
Middleware order is critical:
1. app.Use* (processing order)
2. app.Map* (routing rules)
3. app.Run() (final endpoint)
Fixes: 500 error on /admin/_framework/blazor.webassembly.js
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- @page "/sitemap.xml" (explicitly named route)
- Accessible at /taxbaik/sitemap.xml for search engines
- Matches robots.txt sitemap reference
- Dynamic content from DB on every request
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Delete wwwroot/sitemap.xml (static file blocking dynamic)
- Sitemap.cshtml now generates fresh URLs from DB on every request
- Includes blog posts, FAQ, announcements, contact pages
- Portal and admin pages remain excluded from robots.txt
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Change from AddInteractiveWebAssemblyRenderMode() to AddInteractiveServerRenderMode()
- Project structure doesn't support WebAssembly hosting model yet
- Server render mode uses existing Blazor Server infrastructure
- Fixes 404 errors and infinite loading screen
This is a temporary fix to restore admin functionality.
WebAssembly migration can be done in a separate phase with proper project restructuring.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Add AddAdditionalAssemblies(typeof(TaxBaik.Web.Components.Admin._Imports).Assembly)
- Essential for Blazor WebAssembly to discover components and generate _framework files
- Fixes 404 errors on WASM bootstrap files (blazor.webassembly.js, dotnet.wasm, etc)
This resolves the infinite loading screen after admin login.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Load Google Fonts asynchronously using media="print" + onload
- Add noscript fallback for non-JavaScript environments
- Prevents blocking Blazor WASM initialization
This fixes the loading screen freeze issue where fonts
from Google CDN were blocking WASM bootstrap completion.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Changed test message from "문의합니다." (5 chars) to
"사업자 세무 관련해서 문의드립니다." (18 chars) to comply
with the new 10-character minimum message length validation.
All tests now pass: 26/26 ✓
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Add SameSite=Lax to session cookie
- Add SecurePolicy=SameAsRequest for proxy compatibility
- Explicitly configure Antiforgery cookie with same settings
- Resolves antiforgery token validation failures on HTTPS
This fixes the "required antiforgery cookie is not present" error
that occurs when behind Nginx reverse proxy with HTTPS.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- DataAnnotations: Current default for basic validation
* Required, StringLength, RegularExpression, etc.
* Built-in framework, lightweight
- FluentValidation: For complex business logic (future)
* Conditional validation
* Database queries (duplicate checks)
* Cross-field validation
* Examples and integration steps provided
Clear decision rule: Use DataAnnotations now, adopt FluentValidation
when complex validation is needed. Never mix both in same DTO.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Add [Required], [StringLength], [RegularExpression] to all fields
- Name: Required, max 100 characters
- Phone: Required, Korean phone number regex validation
- Email: Optional, email format validation
- ServiceType: Optional, max 50 characters
- Message: Required, 10-5000 characters
- Status (UpdateInquiryDto): Required
- AdminMemo: Optional, max 1000 characters
Provides automatic validation at DTO layer via DataAnnotations.
All error messages are user-friendly in Korean.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Input validation pattern: client + server dual validation
- Korean phone number handling: supported formats and regex
- Message content length limits: 10-5000 characters
- DTO and DataAnnotations rules
- Telegram notification integration pattern
- On-site validation checklist for new forms
Establishes development standards for all future features.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Backend: MinMessageLength=10, MaxMessageLength=5000
- Frontend: Real-time character counter
- Frontend: Client-side validation before submission
- Frontend: Error messages for length violations
- Applied to both Submit and Update operations
Prevents empty or excessively long messages while maintaining
user-friendly feedback on character count.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Add comprehensive Korean phone number regex validation
- Support all area codes: 02, 031-064, 070, 0505-0509
- Support all mobile carriers: 010-019
- Intelligent formatting based on area code (2-3 digits)
- Client-side JavaScript: real-time formatting + validation
- Backend C#: robust validation + formatting for storage
Handles all Korean phone number formats:
- Landline: 02-123-4567, 031-1234-5678
- Mobile: 010-1234-5678
- VoIP: 070-1234-5678, 0505-1234-5678
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- 10-digit numbers: XXXX-XXX-XXXX (4-3-3) - landline format
- 11-digit numbers: XXX-XXXX-XXXX (3-4-4) - mobile format
Apply consistent formatting on both frontend and backend.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Add real-time phone number formatting (XXX-XXXX-XXXX pattern)
- Validate phone length (10-11 digits) before form submission
- Show validation error message to user
- Only numeric input allowed with auto-formatting
- Improves UX: users see formatted result immediately
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Accept phone numbers with or without hyphens/spaces (01012345678, 010-1234-5678, etc)
- Auto-format to standard 010-XXXX-XXXX or 010-XXXX-XXXXX format on backend
- Remove strict regex validation that forced user input format
- Better UX: accept user input as-is and normalize in backend
Closes issue with phone number validation being too strict.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Today's incident: CI reported successful deploys while the real site
returned 502 (root) then 404 (/taxbaik/) to users. Root cause was three
compounding Nginx issues, none of which the previous CI checks could see
because they only ever curled 127.0.0.1:5001 directly, bypassing Nginx:
1. Two Nginx config files existed. sites-available/default (documented,
but NOT symlinked into sites-enabled/) was being edited repeatedly with
zero effect. The file actually loaded was
sites-available/taxbaik-domains.conf (-> sites-enabled/), undocumented.
2. That real file hardcoded the Green-Blue app port (5003) directly in
both `location /` and `location /taxbaik`, instead of the persistent
TaxBaik.Proxy on 5001. When the active port flipped to 5004, Nginx kept
pointing at the dead 5003 -> 502.
3. Fixing the port to 5001 with a trailing slash on proxy_pass triggered
Nginx URI rewriting, sending a double slash ("//") to the backend,
which 404'd. Confirmed via `curl http://backend//` -> 404.
Changes:
- deploy.yml: replace the old blind `grep sites-available/default` check
(checked the wrong, unloaded file) with a hard-failing check that (a)
resolves the actual file via sites-enabled/ symlinks, (b) fails the
deploy if either location block hardcodes 5003/5004 instead of 5001,
(c) fails if /taxbaik's proxy_pass carries a stray trailing slash.
- deploy.yml: add an external, post-deploy check that curls the real
public domain (www.taxbaik.com root, /taxbaik/, /taxbaik/admin/login)
through Cloudflare + Nginx, with retries — this is what would have
caught the whole incident on the very first broken deploy instead of
requiring live user reports.
- deploy_gb.sh: drop the stale comment implying Nginx needs updating
per-deploy; it never should, since Nginx always points at the
persistent 5001 proxy which reads taxbaik_port itself.
- CLAUDE.md: document the real config file, the 5001-only invariant, the
proxy_pass trailing-slash gotcha, and the Host-header/SNI trick for
testing domain-based server blocks locally; record the incident in the
CI troubleshooting harness section.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
DISCOVERY:
- Nginx was incorrectly set to port 5004 (app server)
- Correct setting is port 5001 (TaxBaik.Proxy)
- Proxy reads taxbaik_port file and auto-routes to active port
ARCHITECTURE:
Nginx (5001) → TaxBaik.Proxy (5001) → Active Port (5003/5004)
FIX:
- Added validation in CI workflow to check Nginx config
- Manual intervention note for operators
- Will prevent 404 errors on next deployment
IMMEDIATE ACTION REQUIRED:
Server operator must run on 178.104.200.7:
sudo sed -i 's|proxy_pass http://127.0.0.1:500[34];|proxy_pass http://127.0.0.1:5001;|g' /etc/nginx/sites-available/default
sudo nginx -t && sudo systemctl reload nginx
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
kjh2064