Базовая аутентификация с Sencha Touch или ExtJS

Итак, у меня есть модель пользователя и магазин пользователей. Когда пользователь аутентифицируется, как лучше всего управлять жизненным циклом этого аутентифицированного пользователя? Мой текущий подход: 1. У меня есть магазин всех пользователей («UsersStore») с моделью для «Пользователь» 2. У меня есть второй магазин для аутентифицированных пользователей («AuthenticatedUsersStore») с моделью для «AuthenticatedUser», 3. Оба они имеют отдельные конечные точки REST.Базовая аутентификация с Sencha Touch или ExtJS

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

Может кто-нибудь указать мне в правильном направлении? Любая помощь высоко ценится! Благодаря!

источник

2013-11-19 John Doe

Модель аутентификации пользователей, которую я обычно реализую в приложении, заключается в том, что текущий пользователь приложения не имеет идентификатора, пока они не предоставили учетные данные для внутреннего сервера. Обычно это делается с помощью формы входа в систему (электронная почта/пароль.)

Когда сервер отвечает успешно, он устанавливает свою собственную информацию аутентификации в файле cookie и обычно также возвращает информацию о пользователе, которую требует приложение. Эта информация затем я вставляю в модель и/или хранилище. В зависимости от того, был ли я реализован сервер или кто-то другой, я либо вручную заполняю модель/магазин, либо автоматически.

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

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

источник

2013-11-20 17:32:56

Большое спасибо за ваш комментарий Macy. Итак, скажем, для приложения, в котором у меня есть набор поставщиков (таких же, как у пользователей), у которых есть профили (и связанные данные), которые являются общедоступными, а для аутентифицированного поставщика - намного больше данных. Я ранее реализовал его как поле для пользовательской модели в хранилищах пользователей, но я обнаружил, что у меня было много «hasMany» отношений от пользователя к другим моделям в моем приложении, которые применяются только к аутентифицированному пользователю, и поэтому он чувствовал себя излишним есть все эти ассоциации, но быть пустым и для каждого другого пользователя. Мысли? –

Я бы реализовал это как имеющее одну модель, Vendor, с базовым свойством и ассоциациями. Затем я расширил эту модель с помощью AuthenticatedVendor, которая объявила больше полей и соответствующих методов. Таким образом, ваши модели Vendor не засоряются ненужными полями и методами, но ваши модели AuthenticatedVendor могут использовать функциональность базового Vendor. –

Arite. Имеет смысл. Пользователь My User и Authenticated User расширил общий базовый класс, но это имеет смысл. Я попробую. Спасибо! –

Базовая аутентификация с Sencha Touch или ExtJS

ответ

Смежные вопросы