Разбор tcx файла с Garmin навигатора для построения на основе данных графиков через WEB-интерфейс.

[Stasroot1]

Спасибо. Вселяете оптимизм.

Вроде как у меня получилось то что я хотел.
По моим скриптам: Сначала читаю uid потом tid Потом формирую таблицу в которой указаны все круги и все точки для этого tid.

Вот как это сейчас выглядит:

Так что пока вроде все потихоньку продвигается.

[Stasroot1]

Доброго времени суток. Заткнулся на развилке на которой пользователю предоставляется вывбор дальнейшего варианта событий: Просмотр тренировок и Загрузка файла на сервер.
Сначала авторизация... после того как она прошла в сессии появляется значение с именем пользователя, идентификатором пользователя.
До того как сделать развилку с выбором скрипт проводил на выбор тренировки и далее шло отображение тренировки.
Проблема в том, что после того как произошел выбор "Просмотр тренировки" переменная с именем пользователя становится пустой и php выводит сообщение: Notice: Undefined index: uname in /home/srv/www/vhosts/garmin/authorization.php on line 9 Call Stack: 0.0001 638312 1. {main}() /home/srv/www/vhosts/garmin/authorization.php:0

Не могу отследить где теряется значение переменной.

[drBatty]

Проблема в том, что после того как произошел выбор "Просмотр тренировки" переменная с именем пользователя становится пустой

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

Код: Выделить всё

<input type='hidden' name='var' value='999' />

в след. сессии можно прочитать значение var так:

Код: Выделить всё

$var = $_POST['var'];

(естественно нужно учитывать, что злоумышленник может подставить тут любое своё значение)

[Stasroot1]

переменные между сессиями не сохраняются.

А как же массив $_SESSION ? Разве он не глобальный? В моем случае я полагаю (но похоже ошибаюсь) если я присвоил элементу массива $_SESSION['uname'] значение uname то разве это значение не сохряняется пока я его явно не изменю/удалю?
Я присваиваю так:

Код: Выделить всё

$_SESSION['uname'] = $_POST['uname'];
$uname = $_SESSION['uname'];

[drBatty]

А как же массив $_SESSION ? Разве он не глобальный?

не. он суперглобальный.

В моем случае я полагаю (но похоже ошибаюсь) если я присвоил элементу массива $_SESSION['uname'] значение uname то разве это значение не сохряняется пока я его явно не изменю/удалю?

всё дело в том, что на самом деле, вызов скрипта каждый раз начинается с нуля. Т.е. переменные от вызова к вызову НЕ сохраняются. Механизм "сессий" является искусственным костылём - данные из $_SESSION отправляются клиенту, а потом возвращаются этим клиентом обратно. Лично я этим костылём не пользуюсь, из-за его глючности да и из-за его небезопасности. ИМХО проще самому сформировать идентификатор сессии, и передавать его в каждом запросе (методом PUT, GET, или в куках). Т.к. у нас всё равно есть СУБД, то и всю информацию сессии можно хранить в этой БД. В этом случае злоумышленник не сможет каким-то образом изменить, и даже просмотреть информацию, которую мы передаём между вызовами скрипта.

кстати, вы не забыли эту вашу сессию запустить? см. http://www.php.net/manual/ru/function.session-start.php

[Stasroot1]

не. он суперглобальный.

Спасибо. Как рас тут я и ошибался по ходу. Думая, что он суперглобальный.

кстати, вы не забыли эту вашу сессию запустить? см. http://www.php.net/manual/ru/function.session-start.php

Думаю что не забыл так как в настройках php у меня установлен параметр: session.auto_start = 1 в соответствии с http://www.php.net/manual/ru/session.confi...sion.auto-start стоит в настройках 1.

всё дело в том, что на самом деле, вызов скрипта каждый раз начинается с нуля.

Это мне хорошо понятно. Применяются только суперглобальные переменные.

Т.е. переменные от вызова к вызову НЕ сохраняются. Механизм "сессий" является искусственным костылём - данные из $_SESSION отправляются клиенту, а потом возвращаются этим клиентом обратно. Лично я этим костылём не пользуюсь, из-за его глючности да и из-за его небезопасности. ИМХО проще самому сформировать идентификатор сессии, и передавать его в каждом запросе (методом PUT, GET, или в куках).

Пожалуй буду все это через БД делать, если это безопаснее, думаю несколько дополнительных запросов в БД сервер не нагрузят. В таком случае к таблице users стоит добавить какие то поля: (буду думать какие и как).

Т.к. у нас всё равно есть СУБД, то и всю информацию сессии можно хранить в этой БД. В этом случае злоумышленник не сможет каким-то образом изменить, и даже просмотреть информацию, которую мы передаём между вызовами скрипта.

Т.е. всякие GET POST исключаем. Мне это может и сложнее но ради дела... надо освоить.

[drBatty]

Думаю что не забыл так как в настройках php у меня установлен параметр: session.auto_start = 1 в соответствии с http://www.php.net/manual/ru/session.confi...sion.auto-start стоит в настройках 1.

а... ну тогда ОК.

Это мне хорошо понятно. Применяются только суперглобальные переменные.

совсем не потому, что они суперглобальные. А потому, что они встроенные, т.е. ближе к встроенным функциям. Т.е. это, строго говоря, вообще не переменные, а некие методы, для получения информации. Создатели php просто их оформили как "переменные", по типу как в bash есть "переменная" $RANDOM, которая принимает случайное значение от 0 до 32767 при каждом чтении.

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

не нагрузят конечно. Сессии они тоже через СУБД могут делаться, дело в том, что сложно сказать, КАК оно реализовано на сервере.

В таком случае к таблице users стоит добавить какие то поля: (буду думать какие и как).

а вот это зря. Нужно отдельную таблицу делать, ибо юзеры будут открывать несколько сессий. Вот такие они плохие.

Т.е. всякие GET POST исключаем.

нет конечно. пусть будут.

[Stasroot1]

а вот это зря. Нужно отдельную таблицу делать, ибо юзеры будут открывать несколько сессий. Вот такие они плохие.

Дамс... т.е. лучше сделать таблицу типа:
CREATE TABLE user_session (session_id INT NOT NULL, session_uid INT, session_string TEXT)
И заполнять ее синхронно с регистрацией пользователя в системе, т.е. пользователю назначать единственный идентификатор сессии, ставить его в NULL при регистрации и обновлять его запросом типа UPDATE ... при авторизации и обновлять каждый рас когда из сессии изымаются какие то данные или какие то добавляются. Таким образом как я понимаю уже зайдя с любого компьютера / браузера под своим именем пользователь автоматом получит те значения сессии которые были в конце работы в прошлый рас. Как то так.

При этом индекс и первичный ключ думаю сделать по session_uid полю и завязать его на поле uid таблицы users через вторичный ключ... как то так.

нет конечно. пусть будут.

ОК пускай будут тогда.

[Stasroot1]

Вот такая получится схема примерно:

И SQL который Эту таблицу организует:

Код: Выделить всё

CREATE TABLE IF NOT EXISTS `user_session` (
  `session_uid` int(11) unsigned NOT NULL COMMENT 'соответствует uid полю таблицы users',
  `session_id` int(10) unsigned DEFAULT NULL COMMENT 'идентификатор сессии пользователя',
  `session_string` text COLLATE utf8_bin COMMENT 'Строка массива данных сессии.',
  PRIMARY KEY (`session_uid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

-- Дамп данных таблицы `user_session`

INSERT INTO `user_session` (`session_uid`, `session_id`, `session_string`) VALUES
(1, NULL, NULL),
(2, NULL, NULL);

-- Ограничения внешнего ключа сохраненных таблиц

-- Ограничения внешнего ключа таблицы `user_session`
ALTER TABLE `user_session`
  ADD CONSTRAINT `user_session_ibfk_1` FOREIGN KEY (`session_uid`) REFERENCES `users` (`uid`) ON DELETE CASCADE ON UPDATE CASCADE;

[Stasroot1]

можно ли вообще отказаться от использования $_SESSION[] ? я чего то запутался, думаю теперь по новой начинать переписывать свои скрипты. Только пока не пойму как.

Проблема которую не понимаю на данный момент:
есть некоторый пользователь с именем first это пользователь с uid =1 ... Но это в БД.
Как используя БД можно в последующих скриптах делать запросы типа: $sql_select="SELECT session_uid, session_string FROM user_session WHERE session_uid = $uid"; Когда этот самый $uid и надо прочитать в сессии в последующих запросах к сессии...

Наверное по вопросу видно что я запутался.

[drBatty]

Дамс... т.е. лучше сделать таблицу типа:
CREATE TABLE user_session (session_id INT NOT NULL, session_uid INT, session_string TEXT)
И заполнять ее синхронно с регистрацией пользователя в системе

не. если вы хотите сделать для одного юзера ОДНУ сессию, то тогда добавляйте поля в таблицу юзеров. Вот только так лучше таки не делать, потому-что если юзер зайдёт скажем с мобилы, то он как-бы будет продолжать сессию на своём компьютере (ибо юзеры никогда не пользуются кнопкой "выход", и вообще не понимают, зачем она). Юзеры желают, что-бы при входе с мобилы сессия начиналась "с нуля". Кстати, для админа и тестера это тоже удобно. Ну может кто-то тут что-то и другое скажет, мне тоже это интересно, вот только я статистику по сайтам смотрю - юзеры входят с разных мест, и им удобнее именно так, что-бы с каждого рабочего места была своя сессия, которая и продолжалось-бы заданное время. Как всегда - ИМХО.

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

а это надо? ИМХО совсем нет. Если на этом форуме я сейчас пишу это сообщение(с десктопа жены), разве я жду того, что зайдя с моей мобилы я буду дописывать это-же сообщение? Нет конечно!

можно ли вообще отказаться от использования $_SESSION[] ? я чего то запутался, думаю теперь по новой начинать переписывать свои скрипты. Только пока не пойму как.

понимаете, $_SESSION это на самом деле точно такая-же схема, что и я вам предложил. Просто $_SESSION это встроенная схема. ИМХО встроенную есть смысл использовать только после того, как вы поймёте, КАК она работает. Ну если конечно вы не хотите стать быдлокодером, который не понимает, что такого плохого, в забивании шурупов микроскопом. (:
ну две схемы сразу конечно смысла использовать нет. Это как забивать один шуруп попеременно молотком и микроскопом.

[drBatty]

Когда этот самый $uid и надо прочитать в сессии в последующих запросах к сессии...

возвращаемся к началу:
1. юзер вводит логин/пароль
2. нажимает ОК, и получает session ID (sid)
3. вот тут начинается сессия, в которой в частности хранится user ID ($uid). Сессию можно хранить в COOKIES, а можно передавать её в каждой POST форме как echo "<input type='hidden' name='sid' value='$sid' />";
(методом GET передавать sid лучше не надо, ибо один юзер может дать ссылку со своим sid'ом другому юзеру, что приведёт к передаче сессии этому другому юзеру.)

[Stasroot1]

не. если вы хотите сделать для одного юзера ОДНУ сессию, то тогда добавляйте поля в таблицу юзеров. Вот только так лучше таки не делать, потому-что если юзер зайдёт скажем с мобилы, то он как-бы будет продолжать сессию на своём компьютере (ибо юзеры никогда не пользуются кнопкой "выход", и вообще не понимают, зачем она). Юзеры желают, что-бы при входе с мобилы сессия начиналась "с нуля". Кстати, для админа и тестера это тоже удобно. Ну может кто-то тут что-то и другое скажет, мне тоже это интересно, вот только я статистику по сайтам смотрю - юзеры входят с разных мест, и им удобнее именно так, что-бы с каждого рабочего места была своя сессия, которая и продолжалось-бы заданное время. Как всегда - ИМХО.

Вот тут я еще не решил. Дело в том, что мне казалось бы логичным запретить использование сервиса с нескольких устройств особенно по части загрузки данных в БД.
Да пользователи не любят жать кнопку выход и все такое. Сам с ними по этому поводу разъяснительные работы периодически с примерами провожу...
Да писать с другого устройства то что начинал писать с первого устройства нет смысла, однако предложить пользователю зашедшему под тем же ником форму в которой он только что или час назад вводил текст вполне разумно, в этом случае он сможет избежать каких то дополнительных действий по добиранию к месту заполнения гепотетической формы.... К тому же это специфический по своему характеру сервис а не социальная сеть в которой потеря0некорректное сохранения сообщения своей подруге\другу не является критичным происшествием в отличии от например заводки данных по тренировке. Может быть я слишком идиализирую ситуацию, но ... ведь по сути у нас импорт данных в БД будет реализовываться как монолитная операция выполняемая либо на одном компе либо на другом, тут не важно - операция либо выполнена, либо нет, к тому же сама архитектура (схема) нашей БД вроде как рас расчитана на то, что при ошибках данные не впишуться частично а только полностью за всю тренировку.
Вспомните с чего начиналась тема в форуме... требовалось отредактировать файл так, чтобы его было удобнее смотреть, т.е. удалить явные ошибки прибора по записи трекпоинтов. Соответственно я полагаю, что было бы логично отредактировав ряд точек на одной машинке (браузере) продолжить редактирование на другой машинке (браузере) и отредактировав все это отправить изменения в БД одним запросом. И... было бы совсемхороошо предоставить возможность указывать время жизни сессии от десятка минут до суток к примеру, чтобы отредактировав часть массива своих данных, он смог продолжить работу через указанное время а не начинал все с начала.
Скорее всего это сильно усложняет процесс разработки и возможно тестирования, хотя про тестирование еще не факт, так как нет разветвленности сессий для пользователя и все двигается по более простому сценарию с одной сессией.
ВСЕ ИМХО основанное не на опыте работы а на общих представлениях, к тому же может где то и не правильных или воввсе отсутствующих... однако человек опытный в разработке может увидеть в них какое то зерно и подправить ход мысли или наоборот его развить.

Делая одну сессию для одного пользователя приследую задачи:
1. Повысить устойчивость БД к одинаковым записям в последнюю (даже если так, то зачем делать идентичную работу дважды?).
2 . Пользователь ДОЛЖЕН работать атомарно, операция за операцией без параллельности выполнения одинаковых операций ясное дело для одинаковой тренировки или их набора.
3. Вроде так проще уследить за целостностью данных на стороне PHP как бы в дополнение к целостности которая проверяется (должна проверяться) на стороне сервера БД.

[drBatty]

Делая одну сессию для одного пользователя приследую задачи:
1. Повысить устойчивость БД к одинаковым записям в последнюю (даже если так, то зачем делать идентичную работу дважды?).
2 . Пользователь ДОЛЖЕН работать атомарно, операция за операцией без параллельности выполнения одинаковых операций ясное дело для одинаковой тренировки или их набора.
3. Вроде так проще уследить за целостностью данных на стороне PHP как бы в дополнение к целостности которая проверяется (должна проверяться) на стороне сервера БД.

ИМХО это всё несущественно. Но если хотите сделать только одну сессию для одного юзера, тогда наверное нет смысла заводить отдельную таблицу сессий, а проще добавить поля в users. проще всего после успешного ввода логина/пароля выдать юзеру куку с уникальным числом типа 68b329da9893e34099c7d8ad5cb9c940, а далее проверять это число. Число можно сделать смешав md5(microtime() . ip юзера . юзерагент . "какая-то строка"), и сохранить его в $_COOKIE и в строчке юзера. Там же нужно сохранить время создания нашей куки (т.к. она имеет срок действия)

В самом начале скрипта нужно проверить наличие куки, и если она есть, и если она совпадает с какой-то кукой какого-то юзера, и если она не устарела, то нужно продолжать текущую операцию. Иначе надо просить логин/пароль. У такой схемы есть два недостатка:
1. это не сработает с отключёнными куками. Ну это проблема юзеров-идиотов, и нас она не должна волновать.
2. предположим, юзер сидит за десктопом, и что-то там делает. Всё работает по его куке. Потом юзер куда-то уходит, и что-то делает с нетбука. Т.к. кука осталась на десктопе, его попросят ввести логин/пароль, а далее всё будет работать как надо. Когда юзер придёт домой и вновь сядет за десктоп, его выкинут опять вводить логин/пароль, ибо его десктопная кука уже не работает, даже если десктоп не выключался, и браузер не закрывался.

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

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

ну это по любому будет так. в любом случае у нас операция выполняется за один прогон скрипта, и никакие куки/сессии никак на это не влияют.

[Stasroot1]

Вчера закончились соревнования Кубок РФ по гребле на байдарках и каноэ. Шли они долго почти неделю. к компу почти не подходил. Сейчас потихонбку возвращаюсь к работе над проектом.