2013-08-31 3 views
0

Итак, это меня озадачивает.Настройка user_data в сеансе, дающая разные результаты

Когда пользователь входит в систему I установить UserData в сессии так:

$data = array(); 
$data['email'] = $this->input->post('email'); 
// get the user's info where it matches their email in the db. 
$user = $this->User_model->get_user($data); 
$this->session->set_userdata('user_session', $user); 

Теперь это прекрасно работает. Он создает user_session в данных сеанса как объект. С кем я в порядке.

Затем, когда пользователь обновляет свою информацию, я хочу сбросить данные в user_session, чтобы они соответствовали их новым данным. Я делаю это так:

$data = array(
    'first_name' => $this->input->post('first_name'), 
    'last_name' => $this->input->post('last_name'), 
    'email' => $this->input->post('email'), 
    'phone' => $this->input->post('phone'), 
    'street1' => $this->input->post('street1'), 
    'street2' => $this->input->post('street2'), 
    'city' => $this->input->post('city'), 
    'state' => $this->input->post('state'), 
    'zip' => $this->input->post('zip'), 
    'password' => $encrypted_password, 
    'organizations_id' => $this->input->post('org_select') 
); 

$user = $this->User_model->get_user($data); 
$this->session->set_userdata('user_session', $data); 

Теперь $data здесь используется, чтобы обновлять информацию в БД, а затем повторно использовать его, чтобы вывести свои данные из с помощью индексации на их email.

Наконец, здесь метод я использую модель для обоих из них:

public function get_user($data) 
{ 
    return $this->db 
     ->where('email', $data['email']) 
     ->select('first_name, last_name, email, password, id, organizations_id') 
     ->get('users') 
     ->row(); 
} 

Это работает, но по-разному. Вместо того, чтобы давать мне объект, он просто дает мне массив. Это вызывает целый ряд проблем в другом месте моего кода.

Как мне управлять властью или нет, это дает мне объект или массив?


EDIT:

Я реализовал идиот ход. Я отправил $data вместо $user в свою модель, когда пользователь изменил свою информацию.

Поэтому я исправил проблему, и теперь я получаю объект оба раза. Но я все еще хочу знать, как эти два метода дали разные результаты. Таким образом, я могу контролировать это в будущем.

Так что с этим, как говорится, вот мой ОФИЦИАЛЬНЫЙ ВОПРОС:

Как контролировать ввод данных сеанса, так что это либо массив или объект?

ответ

0

ну наилучший вариант - создать поле под названием uniqueid в таблице пользователей. при создании пользователя - генерировать случайную строку - это ваш уникальный идентификатор - включить ее в данные вставки.

создать новый сеанс - сохранить только уникальный идентификатор.

тогда, когда вы обновляете таблицу Users - уникальный идентификатор в сеансе остается неизменным. вы возвращаете обновленный результат вашему контроллеру, и вам не нужно суетиться с сеансом.

типичный процесс после того, как уникальный идентификатор устанавливаются:

  • получить уникальный идентификатор от сессии
  • поиска пользователей таблицы с уникальным идентификатором
  • пользователями таблица возвращает объект (или массив), содержащие поля, которые вы нужно
  • использовать этот объект пользователя в приложении (не сеанс)

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

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

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

так, то с уникальным идентификатором - вы получите обратно объект скажем под названием $ editsession с легко получить при значениях, как $ editsession-> $ Идентификатор_пользователя editsession-> storyid $ editsession-> Статус

// example get your user 
if(! $user = $this->user->_get($editsession->userid) ;) 
{ $this->_error() ; } 
else { $this->_showEditor($user) ;} 

и это пример генератора случайных строк

$uniqueid = random_string('alnum', 10); 

Наконец-то обратите внимание, что я называю модель просто «пользователем». даже месяц назад я бы добавил '_model' или '_m' к имени файла модели. , но это неправильно - он просто добавляет шум - так что просто выходите из привычки, и ваш код будет намного чище. все файлы явно находятся в папке под названием models :-)

+0

Это действительно хорошая идея. Нужно ли это быть случайной строкой? или я могу просто использовать автоматически увеличивающийся номер в db (вот как он настроен в данный момент в любом случае. каждый пользователь имеет свой собственный уникальный номер, но его не случайный) – JDillon522

+0

ответил (а) в правой части – cartalot

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