Files
bentopdf/docs/be/self-hosting/cors-proxy.md
T

181 lines
10 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# CORS-проксі для атрымання сертыфікатаў
Інструмент лічбавага подпісу выкарыстоўвае CORS-проксі, каб атрымліваць сертыфікаты выдаўцоў ад знешніх цэнтраў сертыфікацыі (CA). Гэта неабходна, бо многія серверы CA не ўключаюць загалоўкі CORS у свае адказы, што не дазваляе атрымліваць іх непасрэдна з браўзера.
Акрамя таго, многія серверы CA аддаюць сертыфікаты праз звычайны HTTP. Калі ваш экзэмпляр BentoPDF працуе праз HTTPS, браўзеры блакіруюць такія HTTP-запыты (палітыка змешанага кантэнту). CORS-проксі вырашае абедзве праблемы, накіроўваючы запыты праз HTTPS-адрас з правільнымі загалоўкамі.
## Як гэта працуе
Пры подпісе PDF сертыфікатам:
1. Бібліятэка `zgapdfsigner` спрабуе пабудаваць поўны ланцужок сертыфікатаў
2. Яна атрымлівае сертыфікаты выдаўцоў па URL, укладзеных у пашырэнне AIA (Authority Information Access) вашага сертыфіката
3. Гэтыя запыты праходзяць праз CORS-проксі, які дадае неабходныя загалоўкі `Access-Control-Allow-Origin`
4. Проксі вяртае даныя сертыфіката браўзеру
## Уласнае размяшчэнне CORS-проксі
Калі вы размяшчаеце BentoPDF у сябе, вам трэба разгарнуць уласны CORS-проксі, каб лічбавыя подпісы працавалі з сертыфікатамі, якія патрабуюць атрымання ланцужка.
### Варыянт 1: Cloudflare Workers (рэкамендуецца)
1. **Усталюйце Wrangler CLI**:
```bash
npm install -g wrangler
```
2. **Увайдзіце ў Cloudflare**:
```bash
wrangler login
```
3. **Скланіруйце BentoPDF і абнавіце дазволеныя крыніцы**:
```bash
git clone https://github.com/alam00000/bentopdf.git
cd bentopdf/cloudflare
```
Адкрыйце `cors-proxy-worker.js` і змяніце масіў `ALLOWED_ORIGINS` на ваш дамен:
```js
const ALLOWED_ORIGINS = [
'https://your-domain.com',
'https://www.your-domain.com',
];
```
::: warning Важна
Без гэтай змены проксі будзе адхіляць усе запыты з вашага сайта з памылкай **403 Forbidden**. Па змаўчанні дазволены толькі запыты з `bentopdf.com`.
:::
4. **Разгарніце проксі**:
```bash
wrangler deploy
```
Запішыце URL вашага worker (напрыклад, `https://bentopdf-cors-proxy.your-subdomain.workers.dev`).
5. **Перасабярыце BentoPDF з URL проксі**:
Калі выкарыстоўваеце Docker:
```bash
export VITE_CORS_PROXY_URL="https://your-worker.workers.dev"
DOCKER_BUILDKIT=1 docker build \
--secret id=VITE_CORS_PROXY_URL,env=VITE_CORS_PROXY_URL \
-t your-bentopdf .
```
Калі збіраеце з зыходнага кода:
```bash
VITE_CORS_PROXY_URL=https://your-worker.workers.dev npm run build
```
### Варыянт 2: Уласны серверны проксі
Вы таксама можаце стварыць уласны адрас проксі. Патрабаванні:
1. Прымаць GET-запыты з параметрам `url`
2. Атрымліваць URL з вашага сервера (на баку сервера абмежаванняў CORS няма)
3. Вяртаць адказ з гэтымі загалоўкамі:
- `Access-Control-Allow-Origin: https://your-domain.com`
- `Access-Control-Allow-Methods: GET, OPTIONS`
- `X-Content-Type-Options: nosniff`
Прыклад рэалізацыі на Express.js:
```javascript
app.get('/api/cert-proxy', async (req, res) => {
const targetUrl = req.query.url;
// Validate it's a certificate URL
if (!isValidCertUrl(targetUrl)) {
return res.status(400).json({ error: 'Invalid URL' });
}
try {
const response = await fetch(targetUrl);
const data = await response.arrayBuffer();
res.set('Access-Control-Allow-Origin', 'https://your-domain.com');
res.set('Content-Type', 'application/octet-stream');
res.set('X-Content-Type-Options', 'nosniff');
res.send(Buffer.from(data));
} catch (error) {
res.status(500).json({ error: 'Proxy error' });
}
});
```
## Пытанні бяспекі
Уключаны Cloudflare Worker мае некалькі мер бяспекі:
| Функцыя | Апісанне |
| --------------------------- | ------------------------------------------------------------------------------------------------ |
| **Праверка крыніцы** | Дазваляе толькі запыты з даменаў, пералічаных у `ALLOWED_ORIGINS` |
| **Абмежаванні URL** | Дазваляе толькі URL сертыфікатаў (`.crt`, `.cer`, `.pem`, `/certs/`, `/ocsp`, `/crl`) |
| **Блакіроўка прыватных IP** | Блакіруе прыватныя дыяпазоны IPv4/IPv6, link-local, loopback, дзесятковыя IP і хмарныя метаданыя |
| **Бяспека Content-Type** | Вяртае толькі бяспечныя MIME-тыпы сертыфікатаў, блакіруе падмену content-type з крыніцы |
| **Ліміт памеру файла** | Перадае адказ патокам з лімітам 10MB, перарывае загрузку пры перавышэнні |
| **Абмежаванне частаты** | 60 запытаў у хвіліну на IP або IPv6 /64 (патрабуе KV, пры памылках KV прапускае запыты) |
| **Подпісы HMAC** | Неабавязковы подпіс на баку кліента (стрымлівае выпадковыя злоўжыванні) |
### DNS rebinding (уласнае размяшчэнне па-за Cloudflare)
Worker адхіляе любы URL, які разрознаецца ў прыватны або ўнутраны IP. Ён не можа выкарыстоўваць фіксаваны спіс дазволеных хостаў, бо URL ланцужкоў сертыфікатаў вядуць да таго CA, які выдаў сертыфікат (FNMT, карпаратыўныя CA і г.д.), таму адрасы загадзя невядомыя. Гэта пакідае невялікае акно для rebinding: той, хто кіруе DNS свайго дамена, можа аддаць публічны IP для праверкі бяспекі, а праз імгненне прыватны для сапраўднага запыту.
На Cloudflare гэтым немагчыма скарыстацца: Workers не маюць доступу да прыватных IP і адраса метаданых `169.254.169.254`, таму rebind нікуды не вядзе. Проста не давайце worker шляху ўнутр: не падключайце Tunnel, Service або прывязку да прыватнай сеткі (яму патрэбен толькі `RATE_LIMIT_KV`).
Калі вы запускаеце яго па-за Cloudflare (workerd, Node і падобнае) унутры VPC, асяроддзе выканання _можа_ дасягнуць унутраных IP. Пастаўце перад ім брандмаўэр выходнага трафіку і заблакіруйце прыватныя дыяпазоны: `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `127.0.0.0/8`, `169.254.0.0/16` і іх аналагі IPv6. Па-за Cloudflare код праграмы не можа гэтага забяспечыць.
## Адключэнне проксі
Калі вы не хочаце выкарыстоўваць CORS-проксі, задайце зменнай асяроддзя пусты радок:
```
VITE_CORS_PROXY_URL=
```
**Заўвага**: без проксі подпіс сертыфікатамі, якія патрабуюць знешняга атрымання ланцужка (напрыклад, FNMT або некаторыя карпаратыўныя CA), завершыцца памылкай "Failed to fetch".
## Вырашэнне праблем
### "Signing error: TypeError: Failed to fetch"
Звычайна гэта азначае адно з наступнага:
1. **CORS-проксі не настроены**: задайце `VITE_CORS_PROXY_URL` і перасабярыце
2. **Змешаны кантэнт заблакіраваны**: ваш сайт працуе праз HTTPS, а URL выдаўца сертыфіката праз HTTP. CORS-проксі гэта вырашае.
3. **CORS-проксі адхіляе вашу крыніцу**: праверце, што ваш дамен ёсць у масіве `ALLOWED_ORIGINS` у `cors-proxy-worker.js`
### "403 Forbidden" ад проксі
Вашага дамена няма ў спісе `ALLOWED_ORIGINS`. Адрэдагуйце `cors-proxy-worker.js`:
```js
const ALLOWED_ORIGINS = ['https://your-domain.com'];
```
Затым разгарніце нанова: `npx wrangler deploy`
### Праверка проксі
```bash
curl -H "Origin: https://your-domain.com" \
"https://your-proxy.workers.dev?url=http://www.cert.fnmt.es/certs/ACUSU.crt"
```
### Сертыфікаты, якія працуюць без проксі
Некаторыя сертыфікаты ўключаюць поўны ланцужок у файл P12/PFX і не патрабуюць знешняга атрымання:
- Самападпісаныя сертыфікаты
- Некаторыя камерцыйныя CA, якія дадаюць прамежкавыя сертыфікаты
- Сертыфікаты, у якія вы ўручную сабралі поўны ланцужок