Платежи онлайн

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

 

Программингфорум

Есть проблемы с кодом? Нужно написать прогу для курсовой? Не получается запрос к MS SQL? Задай вопрос на прекрасном форуме для программистов — http://www.programmingforum.ru/. Си, Бейсик, Паскал, Веб языки – все темы, только для программистов. Пиши как завещал Дейкстра. Странно почему нет секции только по 1С. Больше бы трафика пришло, но нужны конечно специалисты. Интересная дискуссия в разделе для сишников. Какие-то одни математические ветки, валера там явно пишет курсач +))):

Рекомендую читать и задавать вопросы на программингфоруме!

HTTP сессия

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

На платформе J2EE предусмотрено 3 механизма для поддержания сеанса по протоколу http: на основе cookie, на основе URL (URL rewriting) и на основе ср-в, предусмотренных протоколом SSL (Secure Socket Layer) — протокол сеансового уровня, который м. исп-ть совместно с http. По умолчанию используется механизм на основе cookie. Для идентификации каждого сеанса каждого пользовтеля веб-контейнер генерирует уникальный идент-р и создает свой объект типа javax.servlet.http.HttpSession, к-рый в нем хранится.

Код сеанса (сессии) прикрепл-ся к ответу в виде cookie с именем JSESSIONID. При последующих обращениях, сделанных в рамках одного сеанса, браузер прикрепляет эту полученную ранее cookie к запросу, а по полученному с запросом cookie веб-контейнер определяет принадлежность запроса к той или иной сессии, сравнивая идентификатор, извлеченный из cookie и из объектов http session. Данный мех-м работает только в случае, если поддержка cookie в браузере не отключена.

Механизм на основе URL (URL rewriting) заключается в том, что ид-р сессии прикрепляется к URL в виде get-параметра с именем jsessionid. Этот механизм работает даже тогда, когда cookie отключены. Однако при этом необх-мо внедрять соответствующий get-параметр во все ссылки, ведущие к тому же приложению во всех генерируемых им страницах ответов. Для включения ид-ра сессии в состав URL предусм. спец. метод encodeURL. С помощью этого метода д. обрабатываться все ссылки, к-рые присутствуют на всех страницах ответов.

Протокол SSL предусм. встроенный механизм для поддержания сессии. Он м. используется совместно с протоколом http в случае взаимодействия с веб-контейнером по зашифрованному каналу.

Если запрос не отн-ся ни к одному из существующих сеансов, то начин-ся новый. При этом генерируется идентификатор сессии и созд-ся объект типа javax.servlet.http.HttpSession, в составе которого хранится идентификатор сессии на сервере и который обычно прикрепляется к ответу в виде cookie. Браузер, получив cookie в составе ответа сохраняет ее и потом прикрепляет ее к каждому запросу, к-рый отправляется на тот сервер, с к-рого она была получена. Веб-контейнер, извлекая ид-р сессии из запроса, м. определить, к какому сеансу работы отн-ся этот запрос.

Если в браузере cookie отключены, а веб-приложения не исп-ют URL-rewriting, то каждый запрос такого клиента приводит к созд-ию каждый раз нового сеанса.

Слабая связанность веб-клиента и веб-контейнера требует применения таймаута как единственного надежного ср-ва д/определения момента окончания сеанса работы польз-ля с веб-приложением. По умолчанию прин-ся таймаут в 30 минут. Если в течение таймаута не было обращений от польз-ля, то сеанс этого польз-ля счит-ся завершенным. Соотв-ий объект сессии уничт-ся, а ид-р сессии стан-ся недействительным.

Получить объект сессии м. методом getSession инт-са HttpServletRequest. В этом инт-се есть также метод, к-рый позволяет узнать именно тот ид-р сессии, к-рый пришел с запросом (к моменту получения запроса он м.б. и недействительным), — это метод getRequestSessionId, а также узнать, был ли он передан вместе с cookie (метод isRequestedSessionIdFromCookie) или как get-параметр в составе URL (метод isRequestedSessionIdFromURL). Метод isRequestedSessionIdValid позволяет проверить, вышел ли таймаут сессии, индикатор которой был передан с запросом, или нет.

Интерфейс javax.servlet.http.HttpSession содержат методы, которые позволяют узнать все параметры сессии и работать с атрибутами сессии:

getId — возвр-ет ид-р сессии; getCreationTime — возвр-ет момент создания сессии; getLastAccessedTime — возвр-ет момент последнего обращ-ия польз-ля в рамках этого сеанса; getMaxInactiveInterval — возвращает таймаут сессии; isNew — проверяет, была ли создана сессия при поступлении данного запроса или нет; setMaxInactiveInterval — позв. установить величину таймаута.

Объект сессии так же, как и ServletContext и ServletRequest, м. выступать в роли контейнера д/других объектов-атрибутов. Время жизни атрибутов сессии ограничено временем сеанса работы польз-ля с веб-приложением. Атрибуты сессии — это основной механизм для сохранения информации на сервере м/у обращениями одного и того же пользователя в рамках одного сеанса работы с веб-приложением. Н-р, в виде атрибутов сессии сохр-ют ссылки на Statefull Session beans.
___________________________________________
Не каждый может позволить себе купить мужские золотые часы по дорогой цене! Зато каждый может подсмотреть часы по дешевле, но такие красивые и элегантные. Признак галантного мужчины во все времена были — фрак, сигара и золотые часы. Покупайте мужики!

Перенаправление Java запросов.

Качественные автошины в киеве. Ассортимент просто поражает, цены супер, особенно сейчас. Самое время брать зимнюю резину, чтобы осенью не брать на 20% дороже. Рекомендую!
_________________________

При разработке сложных веб-приложений содержащих несколько веб-компонентов, участвующих в обработке запросов, часто возникает необходимость организовать взаимодействие между ними в рамках процедуры обработки одного запроса. Делается это путем перенаправления запроса, поступившего к одному из веб-компонентов на обработку другому веб-компоненту; Например, запрос на получение списка продукции от производителя, не прошедшего аутентификацию, может быть перенаправлен на страницу ввода имени пользователя и пароля. Перенаправление может выполняться двумя разными способами. Первый основан на механизме, который является частью протокола HTTP. Его суть в том, что клиенту генерируется спец. Перенаправляющий ответ, который не содержит запрошенных данных, а содержит только URL по которому клиенту на самом деле нужно обратиться для их получения. В ответ на этот перенаправленный ответ веб-клиент (браузер) генерирует новый запрос, по полученному URL. Генерация перенаправляемого ответа выполняется методом sendRedirect ин-са javax.Servlet.http.HttpServletResponse.

В качестве параметра ему указывается URL того веб-компонента на который мы перенаправляем клиента (этот URL м.б. указан как относительный).

Специфика данного способа в том, что после генерации перенаправляющего ответа обработка исходного запроса считается законченной и инф-ция о нем теряется.

При использовании метода SendRedirect сущ. ограничения

1. вызавать его можно только тогда, когда ответ в состоянии notCommitted, если ответ сommitted, то вызов приводит к выбросу исключения java.long.IllegalStateException

2. если в момент вызова метода буфер вывода был непустой, он очищается

3. после вызова этого метода запрос считается обработанным, а весь вывод, генерируемый далее, игнорируется

4. после вызова ответ переходит в состояние сommitted.

Второй способ перенаправления заключается в использовании объекта типа javax.Servlet.RequestDispatcher, кот можно получить методом getRequestDispatcher (по относительному URL целевого компонента) или методом getNamedDispatcher (по имени целевого компонента) ин-са javax.servlet.ServletContext

Собственно перенаправление м.б. сделано одним из двух методов ин-са RequestDispatcher

м-дом forward и м-дом include. В обоих случаях в качестве параметров передаются запрос и ответ (ServletRequest, ServletResponse). Метод forward передает запрос на обработку другому компоненту и именно он должен сгенерировать ответ. Ограничения, относящиеся к м. forward аналогичны тем, что имеют место для мет sendRedirect ин-са ServletResponse

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

В ин-се ServletResponse сущ. метод sendError, кот позволяет легко послать в кач-ве ответа клиенту стандартное сообщ-е об ошибке, оформленное специфичным для данной реализации сервера приложений образом с указанием кода ошибки (статуса http-ответа) и сообщ-я об ошибке.

Ограничения для метода sendError такие же, как и для мет sendRedirect