Назад | Перейти на главную страницу

как использовать ACL, зависящий от запроса, в качестве условия в совпадении стик или хранилище ответов стик

В neo4j есть конечная точка транзакционного шифра. Это позволяет клиенту запускать транзакцию базы данных по нескольким запросам REST. Первый запрос открывает новую транзакцию и возвращает URL-адрес, который будет использоваться для последующих запросов к той же транзакции в http Location заголовок, содержащий идентификатор транзакции, например

Location: http://192.168.0.10:7474/db/data/transaction/24

Число в конце - это внутренний идентификатор транзакции. Последующий запрос на закрытие транзакции отправляется на http://192.168.0.10:7474/db/data/transaction/24/commit.

Для этого я использую следующий фрагмент для конфигурации бэкэнда haproxy:

backend neo4j-all
    option httpchk GET /db/manage/server/ha/available
    stick-table type integer size 1k expire 10m
    stick match path,word(4,/) 
    stick store-response hdr(Location),word(6,/) 
    server s1 127.0.0.1:7474 maxconn 32 check
    server s2 127.0.0.1:7475 maxconn 32 check
    server s3 127.0.0.1:7476 maxconn 32 check

Прикрепленная таблица заполняется идентификатором транзакции (6-е слово в заголовке местоположения). Последующий запрос path содержит идентификатор транзакции как 4-е слово. Эта часть работает нормально.

Однако я хочу ограничить использование таблицы стик для путей, начинающихся с /db/data/transaction поскольку у Neo4j могут быть и другие конечные точки с другим поведением.

Мой первый наивный подход заключался в том, чтобы просто добавить acl на бэкэнд:

 acl tx_cypher_endpoint path_beg /db/data/transaction

а затем изменить stick match и stick store-response сверху с if tx_cypher_endpoint. При запуске это вызывает следующее сообщение:

синтаксический анализ [haproxy.cfg: 32]: acl 'tx_cypher_endpoint' никогда не будет соответствовать, потому что он включает только ключевые слова, несовместимые с 'правилом внутреннего хранилища стикеров'

Вопрос №1: кто-нибудь может объяснить причину этого?

В качестве обходного пути я переместил acl в раздел внешнего интерфейса и условно сохранил переменную с txn область видимости, которая используется в серверной части:

frontend http-in
    bind *:8090
    acl tx_cypher_endpoint path_beg /db/data/transaction
    http-request set-var(txn.tx_cypher_endpoint) bool(true) if tx_cypher_endpoint
    default_backend neo4j-all

backend neo4j-all
    option httpchk GET /db/manage/server/ha/available
    acl tx_cypher_endpoint var(txn.tx_cypher_endpoint),bool
    stick-table type integer size 1k expire 10m
    stick match path,word(4,/) if tx_cypher_endpoint
    stick store-response hdr(Location),word(6,/) if tx_cypher_endpoint
    server s1 192.168.0.10:7474 maxconn 32 check
    server s2 192.168.0.11:7474 maxconn 32 check
    server s3 192.168.0.12:7474 maxconn 32 check

Вопрос № 2: является ли описанная выше установка наиболее элегантным подходом или возможна более простая установка?

Вопрос № 3: как я могу увидеть, что происходит внутри haproxy, например какие значения сохраняются в переменной или в таблице стикеров? Это stats socket путь идти? Или есть более подробный вывод консоли, чем при использовании -d?

haproxy neo4j