Sites & keys
Manage the domains and keys that connect your websites to BotShield.
Service: Connecting…
Your websites 0
Keys stay paired with the domains you allow.
| WEBSITE | PUBLIC SITE KEY | STATUS | Actions |
|---|
Your first website starts here.
Add a domain to generate its public key and private secret.
Changes take effect immediately. Your application’s backend enforces the verification result.
Embed & verify
Connect any website with a browser script and a server-side verification call.
Choose your website
Examples below use this website’s public key and your current service address.
Add the browser script
Place it in your template or page. It adds a hidden botshield-token field and obtains a token when a standard form submits.
The public site key belongs here. Your private secret does not. Allow this service in your Content Security Policy’s script-src and connect-src.
Verify before accepting the form
Read the token in your backend and call the verification API over HTTPS. Reject failures and scores below your chosen threshold.
Test both acceptance and rejection
- Submit a fresh token and check that your backend enforces success, isBot and score.
- Submit without a token, then with a modified token. Both must be rejected.
- Verify the same token twice. The second verification must fail.
- Retain normal CSRF protection, input validation and authorization.
Deployment
This administrator website connects to your existing BotShield.Service over HTTPS.
Update the original service
Build BotShield.Service/BotShield.sln and publish its server to the existing API hostname. The updated service adds an authenticated management API and encrypted site storage. Your public script and verification URLs stay the same.
Before the first request, configure the Service role below. Existing BOTSHIELD_SITES registrations are imported once when sites.dat is absent. After migration, the service registry is authoritative.
powershell -File scripts/Connect-Service.ps1 -Role Service -ApplicationPath C:\inetpub\BotShield -ApplicationPoolName BotShieldServiceRun the script from this solution's setup folder on the service's Windows server. Save the separate management key printed once; it is not a website secret.
Deploy and pair this manager
Publish the manager to a separate HTTPS IIS application, with its own pool. It hosts only the admin interface; it does not issue public website tokens.
powershell -File scripts/Initialize-Admin.ps1 -ApplicationPath C:\inetpub\BotShieldManager -Username admin -ApplicationPoolName BotShieldManager
powershell -File scripts/Connect-Service.ps1 -Role Manager -ApplicationPath C:\inetpub\BotShieldManager -ApplicationPoolName BotShieldManager -ServiceUrl https://shield.example.comPaste the management key at the hidden prompt. Both scripts restrict App_Data to SYSTEM, Administrators and the selected pool. Recycle each application's pool after setup.
Sign in at . The service hostname is shown on Sites & keys.
Manage the service from this UI
Create a site here, then confirm that its embed examples point to the service hostname. Domain changes, secret rotation, disabling and deletion are sent to BotShield.Service and take effect there immediately.
The management key stays in this manager's backend. Browser sessions use the administrator login and CSRF protection; browser code never calls the privileged service management API directly.
Back up the correct application data
Back up the service's App_Data directory for registrations, site-change history and its management credential. Back up the manager's App_Data directory for its administrator credential and service connection.
DPAPI files depend on the Windows machine that encrypted them. Copying them to a different machine is not a portable migration. Use securely retained credentials or rotate and reconnect when moving hosts.