Удар по пределу количества символов при создании токенов OAuth

Question

Мы используем WS02 1.90 и столкнулись с проблемой ограничения длины символа в значении области, которое можно назначить для токенов, сгенерированных за сценой.

Например, у нас есть 39 областей, добавленных к 60 конечным точкам API, настроенным в Publisher.

Некоторые из наших отдельных имен областей действия могут содержать до 50 символов, например:

customer-order-authorisation-requests_create

В любом случае, после создания токена для данного пользователя, когда мы попытались получить доступ к API, мы получили сообщение от WSO2, сообщающее нам, что токен доступа недопустим для запрошенного ресурса. Мы дважды проверили значения области, которые мы отправляли в запросе токена, и возвращенные значения области, и можем увидеть соответствующие значения области для рассматриваемого ресурса, на которые есть ссылка в сообщении об ошибке.

После дальнейших копаний в журналах WSO2 мы натолкнулись на следующее:

2017-03-09 10:43:58,845 [-] [pool-46-thread-100] ERROR TokenPersistenceTask Error occurred while persisting access token 60efd3d6b9112d453c451d2965a753e1
org.wso2.carbon.identity.oauth2.IdentityOAuth2Exception: Invalid request
        at org.wso2.carbon.identity.oauth2.dao.TokenMgtDAO.storeAccessToken(TokenMgtDAO.java:196)
        at org.wso2.carbon.identity.oauth2.dao.TokenMgtDAO.persistAccessToken(TokenMgtDAO.java:229)
        at org.wso2.carbon.identity.oauth2.dao.TokenPersistenceTask.run(TokenPersistenceTask.java:56)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)
Caused by: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'TOKEN_SCOPE' at row 1
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3868)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3806)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2470)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2617)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2550)
        at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1861)
        at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1192)
        at org.wso2.carbon.identity.oauth2.dao.TokenMgtDAO.storeAccessToken(TokenMgtDAO.java:188)
        ... 5 more

Если посмотреть на схему базы данных для API Manager, столбец TOKEN_SCOPE находится в таблице IDN_OAUTH2_ACCESS_TOKEN и определен следующим образом:

CREATE TABLE IDN_OAUTH2_ACCESS_TOKEN (
                        ACCESS_TOKEN VARCHAR(255),
                        REFRESH_TOKEN VARCHAR(255),
                        CONSUMER_KEY VARCHAR(255),
                        AUTHZ_USER VARCHAR(100),
                        USER_TYPE VARCHAR (25),
                        TIME_CREATED TIMESTAMP DEFAULT 0,
                        VALIDITY_PERIOD BIGINT,
                        TOKEN_SCOPE VARCHAR(767),
                        TOKEN_STATE VARCHAR(25) DEFAULT 'ACTIVE',
                        TOKEN_STATE_ID VARCHAR (255) DEFAULT 'NONE',
                        PRIMARY KEY (ACCESS_TOKEN),
            FOREIGN KEY (CONSUMER_KEY) REFERENCES IDN_OAUTH_CONSUMER_APPS(CONSUMER_KEY) ON DELETE CASCADE,
            CONSTRAINT CON_APP_KEY UNIQUE (CONSUMER_KEY, AUTHZ_USER,USER_TYPE,TOKEN_STATE,TOKEN_STATE_ID,TOKEN_SCOPE)
)ENGINE INNODB;

В поле TOKEN_SCOPE есть ограничение в 767 символов.

Поэтому для дальнейшей проверки мы начали удалять количество областей, добавляемых через наши API в Publisher, до тех пор, пока значение поля области, возвращаемого в ответе на запрос токена от API токена, не станет ниже этого предела.

Это позволило нам снова получить доступ к нашему API без каких-либо ошибок.

Это проблема для нас, так как у нас только около трети нашего API защищено областями действия.

Конечно, мы можем придумать соглашения об именовании сортировщиков для наших областей, но мы не хотим жертвовать удобочитаемостью этих значений области, поскольку мы используем их в нашем приложении для определения наборов разрешений для зарегистрированных пользователей.

Кажется, что нет никаких ограничений, налагаемых WSO2 при создании и назначении областей в Publisher.

Должны ли мы использовать области каким-либо другим способом? Ограничение в 767 символов кажется довольно специфичным!

Спасибо

Answer 1

Это предел префикса InnoDB.

Если ваша версия MySQL>= 5.7.7, вы можете увеличить размер столбца напрямую. Если нет, вам придется установить innodb_large_prefix значение до увеличения.

См. https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html