Права доступа к SysServerSessions

[Ivanhoe]

DAX 4.0 SP2 FP1 EE
Методом тыка обнаружил, что для чтения таблички SysServerSessions необходимо дать права не только на саму таблицу, но и на ключ AdminDaily (если на него не дать права, то табличка оказывается пустой).

Кто-нибудь может пояснить почему так?

P.S. Доступ к данным проверял через System Documentation.

[Logger]

Наверно вы уже нашли ответ на вопрос, но отвечу.
Причина в том, что на табличке выставлен ключ контроля доступа AdminDaily и выставлено свойство AosAutorization.

А мой вопрос связан вот с чем :
Выявлен глюк ядра, - если для пользователя нет прав на чтение из этой таблички, то при попытке чтения из неё может прерываться выполнение кода, но транзакция не откатывается ((((
У нас это вылезло при вызовах с клиента метода \Data Dictionary\Tables\SysEmailSMTPPassword\Methods\currentAOSInstance

Т.е. при попытке отправить почту работа прерывалась а транзакция не откатывалась.

Кто еще такое встречал и как боролись ?

[someOne]

Да, конечно сталкивались.

Причина скорее в системных таблицах (они участвуют в методе currentAOSInstance таблицы SysEmailSMTPPassword)

SYSclientSessions
SYSserverSessions

На которых видимо, выставлено свойство AosAutorization.

Так как таблицы системные, снять это свойство (AosAutorization) через АОТ с них нельзя.



Можно, например настроить сервер smtp без использования пароля вообще,
(на какой нибудь порт отличный от порта по умолчанию)

У нас работает так

static SMTPPassword password()
{
    CryptoBlob cryptoBlob = connull();
    SysEmailSMTPPassword SMTPPassword;

    AOSId AOSId;
    AOSInstanceId AOSInstanceId;

    ;
    // пришлось сделать так как под правами обычных пользователей не проходит метод
    // SysEmailSMTPPassword::currentAOSInstance() без указания ошибки
    // и почта не отправляется даже в режиме пакета
    // подозреваю что это из за глюка с AosAuthorization

    return "";
    // <---

    [AOSId,AOSInstanceId] = SysEmailSMTPPassword::currentAOSInstance();

    SMTPPassword = SysEmailSMTPPassword::find(AOSId,AOSInstanceId);

    if (SMTPPassword.RecId != 0)
        cryptoBlob = SMTPPassword.Password;

    if (cryptoBlob != connull())
        return cryptoblob2str(WinapiServer::cryptUnProtectData(cryptoBlob));
    else
        return '';
}

- можно наверное прописать пароль как константу в коде
- может попробовать прописать методе таблицы SysEmailSMTPPassword

public static server container currentAOSInstance()
....
clientSessions.skipAosValidation(true);

Я это не пробовал, может поможет ?

[Logger]

Цитата:

Сообщение от someOne

Да, конечно сталкивались.
...
- может попробовать прописать методе таблицы SysEmailSMTPPassword

public static server container currentAOSInstance()
....
clientSessions.skipAosValidation(true);

Я это не пробовал, может поможет ?

Спасибо за ответ.
Да причина именно в этих системных табличках. Мы так как вы написали и сделали, хотя конечно это не совсем правильный способ, но по крайней мере надежный.

А сталкивались вы именно с невозможностью чтения из SYSserverSessions ? (это как раз нормально и правильно) или у вас тоже прерывалась работа без отката транзакции ? (это трындец какой ядреный глюк )

[Ivanhoe]

Так а прав дать не помогает?

[Logger]

Цитата:

Сообщение от Ivanhoe

Так а прав дать не помогает?

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

[someOne]

Цитата:

Сообщение от Logger

А сталкивались вы именно с невозможностью чтения из SYSserverSessions ? (это как раз нормально и правильно) или у вас тоже прерывалась работа без отката транзакции ? (это трындец какой ядреный глюк )

Да сталкивались. Как лечить - не знаю.

Самое надежное как мне кажется, в данной ситуации - это не "завязывать" в транзакцию отправку сообщений по электронной почте. Мало ли глюк с почтой какой. Например начнет почтовый сервер "тормозить" - при этом может зависнуть транзакция в которой идет отправка сообщения. Из за открытой транзакции возникнут блокировки у других пользователей и это может вырасти как снежный ком

Сделал так - почта не отправляется в транзакции (например при разноске накладной), а создается пакетное задание для какой то отдельной пакетной группы.

Соответственно получается два независимых процесса - отправка почты и разноска накладной, и друг другe они уже не могут помешать...

[Logger]

Да, согласен.
У нас тоже есть инструмент по такой отправке почты, только не везде он еще применяется. В перспективе - везде сделаем.

[_AxDevel_]

Тоже сегодня столкнулся с этим багом. Видимо. его уже не вылечат.

[Ivanhoe]

На какой версии системы?

[Garic]

Мда, стрёмный баг.
Помогло skipAosValidation, но запускать его надо обязательно на сервере. Ax4
Как-то так:

PHP код:

public server static str getAOSId()
{
    SysClientSessions clientSessions;
    SysServerSessions serverSessions;
    SkipAOSValidationPermission   permission;
    ;

    select firstonly clientSessions
        where clientSessions.SessionId == sessionId();

    if (!clientSessions)
        return '';
        
    permission = new SkipAOSValidationPermission();
    permission.assert();
    serverSessions.skipAosValidation(true);

    select firstonly serverSessions
            where serverSessions.ServerId == clientSessions.ServerId;

    return serverSessions.AOSId;
} 


[Logger]

Цитата:

Сообщение от Ivanhoe

На какой версии системы?

У нас ядро от RU7
воспроизводится.