среда, 14 марта 2012 г.

Еще немножко про ajax

Когда я писал свой первый пост про ajax, я написал, что в апексе это крайне просто. Так вот, буквально через пару дней апекс продемонстрировал мне, что простота инструмента не освобождает от необходимости учить матчасть. Что я и делал с переменным успехом целый месяц.

Сейчас я работаю над сайтом для публикации информации о соревнованиях по скалолазанию. Для этого, собственно, и начал изучать апекс. Где-то то на конец января было намечено торжественное открытие (регистрация на первые соревнования), а еще через месяц было "боевое крещение" - сами соревнования, информация о которых там сейчас висит. Буквально за несколько часов до того, как адрес должен был быть опубликован, я обнаружил, что за 3 месяца разработки я не вспомнил про элементарнейшую и логичнейшую вещь - я забыл сделать проверку уникальности логинов. Тогда я решил сделать красиво - сделать проверку через ajax. Нашел в интернете примеры, сделал тестовую страничку - работает. На радостях написал сюда пост про то, насколько это просто, и пошел спать. На следующий день сделал проверку логина - а она не работает. Промучился два вечера - не работает, хоть тресни. Но тогда у меня было много проблем и поважнее, я понадеялся на русский авось и на то, что из 40 зарегистрировавшихся людей никто одинаковые логины не придумает. И авось меня не подвел.
Потом, после соревнований, настало время "зализать раны" - пофиксить найденные баги, добавить функций, привести в порядок интерфейс и навигацию. Ну и ajax починить, само собой.
Это была присказка, сказка будет впереди.

Первое, с чего я начал - это со своего же мануала. Взял тестовое приложение, сделал по мануалу страничку - работает. Сделал в "боевом" приложении - не работает. Обсудил ситуацию на форуме - получил кучу советов, но по большей части советовали то, что я и сам уже делал. Всё указывало на то, что у меня не вызывается мой application process. Потом один из участников форума упомянул схемы аутентификации. Это единственное, чем отличались две мои страницы - они были в разных приложениях, и у приложений были разные схемы  аутентификации. Приложение с работающей страницей использовало database authentication, а приложение с неработающей - custom authentication. Я долго изучал доки, но не нашел конкретного упоминания, как именно схема аутентификации влияет на application process. Упоминалось только то, что доступность серверного процесса зависит от применяемой схемы аутентификации. Но больше всего меня смутило то, что при создании серверного процесса в апексе черным по белому написано: "К процессам типа On demand схемы аутентификации и условия (т. е. Conditions) не применяются". А как раз on demand процесс и используется для ajax.  В общем, намечалось обнаружение взаимоисключающих параграфов. Незадолго до этого, вооружившись FireBug'ом, я обнаружил такую вещь: среди post параметров, передаваемых на сервер, были такие два: p_flow_id и p_flow_step_id. Значение первого параметра всегда было ID приложения, а второго - всегда 0. Если мы посмотрим на код javascript функции, делающей ajax вызов, то мы увидим там строку:
var get = new htmldb_Get(null,html_GetElement('pFlowId').value, 'APPLICATION_PROCESS=GET_PHONE',0);
Как мы видим, ID приложения передается в функцию htmldb_get вторым параметром. Осталось дело за малым: найти описание функции htmldb_get (да вот же оно!) и увидеть, что номер страницы передается четвертым параметром. После исправления функции на
var get = new htmldb_Get(null,html_GetElement('pFlowId').value, 'APPLICATION_PROCESS=GET_PHONE',html_GetElement('pFlowStepId').value);
всё заработало!
То есть, по-видимому, защита реализована так, что вызвать application process можно только с той страницы, к которой у пользователя есть доступ. Но с другой стороны, это логично. Если логика серверного процесса зависит от страницы, с которой он вызывается, то нужно проверять, если у пользователя доступ к этой странице, так как пользователю не составит труда подменить номер доступной ему страницы на номер недоступной. А custom authentication схема изначально исходит из предположения, что не все страницы вашего приложения одинаково полезны доступны пользователям.

Комментариев нет:

Отправить комментарий