Функционал Портала Ax2009

[Narayana]

Цитата:

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

Эта система регистрации досталась в наследство еще с портала AX 3.0, когда еще не было входа через домен. С годами микрософт ничего там не меняла, и весь этот сумбур так и перешел в 2009. Потому и документации не существует. Короче без серьезной доработки "все это" использовать нельзя.

Стало быть, документация отчасти должна существовать в Ах 3.0?
А на Ах2012 переделали, не знаете?

[nikos2001]

На AX2012 не знаю, но там и сам процесс регистрации пользователей отличается (для входа можно использовать не только домен). Документация из AX3, если она есть, будет релевантна только в части создания клиента в аксапте, который уже привязан к пользователю. Процесс создание самого пользователя в 2009, естественно, отличается от 3.0

[Narayana]

Цитата:

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

На AX2012 не знаю, но там и сам процесс регистрации пользователей отличается (для входа можно использовать не только домен). Документация из AX3, если она есть, будет релевантна только в части создания клиента в аксапте, который уже привязан к пользователю. Процесс создание самого пользователя в 2009, естественно, отличается от 3.0

Ну, да... ну, да.
То есть, насколько я понял, есть два разных пункта меню с одним названием "Регистрация". Один для создания клиента, - он работает. То есть, дает возможность отправить заявку на регистрацию.
А второй отображает ту же страницу, но с названием "Создать нового пользователя".

При этом, в одном случае используется Managed content EPCSSCustSignUpGuest, в другом EPCSSCustSignUpUser.
Но, оба они как объект используют контрол EPCSSCustSignUp.
Разница только в том, что у Guest есть конфигурационный ключ EP, а у User никакого нет.
Интересно, что бы это значило?
То, что User должен появляться при самых малых правах при заходе анонимом?

[nikos2001]

Идея в том, что с помощью EPCSSCustSignUpUser запрашивается первичный доступ в AX. Администратор AX должен будет вручную создать пользователя в AD и AX, и с помощью формы ECPCustSignUpRequest привязать его к создаваемому на этой же форме клиенту и контакту.

С помощью EPCSSCustSignUpUser запрашивается доступ клиентов на получение дополнительных логинов. Например, если клиент имеет несколько филиалов и каждый филиал должен иметь свой логин. В этом случае Администратор AX должен вручную создать пользователя в AD и AX и с помощью формы ECPCustSignUpRequest и сделать привязку пользователя к создаваемому там же новому контакту.

[Narayana]

Цитата:

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

Идея в том, что с помощью EPCSSCustSignUpUser запрашивается первичный доступ в AX. Администратор AX должен будет вручную создать пользователя в AD и AX, и с помощью формы ECPCustSignUpRequest привязать его к создаваемому на этой же форме клиенту и контакту.

С помощью EPCSSCustSignUpUser запрашивается доступ клиентов на получение дополнительных логинов. Например, если клиент имеет несколько филиалов и каждый филиал должен иметь свой логин. В этом случае Администратор AX должен вручную создать пользователя в AD и AX и с помощью формы ECPCustSignUpRequest и сделать привязку пользователя к создаваемому там же новому контакту.

А вы не знаете, где хранится пароль для нового пользователя, который генерится системой? Отдельной таблицы, вроде, нет.
При этом система генерит пароль, который высылает пользователю по почте со словами "смените при первом входе", но место, где пользователь может сменить пароль, я так и не нашел. Тем более, что, для того, чтобы сменить пароль традиционным способом, нужно лезть на контроллер домена.
Удобнее, конечно, чтобы перед отправкой письма пользователю регистратор вводил бы пароль доменной учетной записи в поле заявки на регистрацию и из него бы система отправляла пароль вместе с логином.
А так получается, что пароль без логина высылается первым письмом, а логин вторым.

И еще одна очень неприятная вещь...
У пользователей интернета нет культуры ввода логина в окошке запроса логина винды вместе с именем домена. Тем более, что отдельного поля для имени домена в форме запроса логин-пароля сейчас нет (было в 2003 сервере).
Соответственно, это вызывает у пользователей смущение.
А если человек не айтишник, то, вообще, не догадается, что запись должна быть "домен\логин" или логин@домен.
Я решил переделать письмо новому пользователю, чтобы логин представлял собой уже запись с доменом, но боюсь, что это все-равно вызовет какой-то процент отказов от регистрации.

[nikos2001]

Цитата:

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

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

Я ж говорю, интеграции с Active Directory (AD) здесь нет никакой. Вся эта функциональность досталась в наследство от предыдущих версий. Посылка этого емэйла - полная бессмыслица в данной реализации! Пароль хранится в поле ECPCustSignUp.TmpPassword

Цитата:

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

И еще одна очень неприятная вещь...
У пользователей интернета нет культуры ввода логина в окошке запроса логина винды вместе с именем домена. Тем более, что отдельного поля для имени домена в форме запроса логин-пароля сейчас нет (было в 2003 сервере).

Чтобы не вводить домен, можно использовать Basic Authentication в IIS. В этом случае домен прописывается при конфигурации Basic Authentication и пользователи вводят обычный логин-пароль. Но Basic Authentication вещь не безопасная (пароль передаются открытым текстом по каналам инета) и поэтому обязательным условием ставится использование протокола HTTPS. Еще можете поиграть с Digest Autherntication в IIS, там домен тоже конфигурируется. Но в свое время я столкнулся с проблемой, что Firefox постоянно переспрашивал логин-пароль, когда использовалась Digest Autherntication

[Narayana]

Посмотрел как обстоят дела в Ax2012, - вроде бы, уже все сделано по человечески.
Форма регистрации нового пользователя в Портале подчищена и, вообще, такое ощущение, что работе с порталом уделено большое внимание. Наверное, то, что разработку перенесли полностью в VS2010, как раз избавляет от необходимости прыгать из одной среды в другую при разработке контролов Портала.