Клиент Банк

← →
Fl@sh © (2006-03-17 22:19) [0]

Доброе время суток.
Я уже наверное надоел Вам с своими нелепими вопросами, но тем не менее всегда жду нужного ответа.
Есть опять 2 вопроса:
1. Платежка, как ее отправлять, т.е. в каком виде. я думал просто делать insert на сервере, но данные ж придется шифровать,
т.е. перед отправкой шифровать закритым ключом каждое поле, а при вставке разшифровка открытим, или лучще блоб поле шифровать, а потом разбирать что куда вставлять, как лучше сделать?
2. FireBird. Создал поле тип float, когда вставляю данные, например 100,12 мне добавляет еще левый мусор, т.е. 100,12435455, почему? как сделать, чтоб был формат 100,12 без мусора в конце. Или какой лучше тип

← →
Fl@sh © (2006-03-17 22:19) [1]

использовать для валюты?

← →
tesseract © (2006-03-17 22:33) [2]

Странный ты.
Платёжка - это документ со многими параметрами, и волновать тебя вопрос должен - чтобы всё точно И ОТ КОГО ПЛАТЁЖ ПРОШЁЛ.

левый мусор - это нормально. округление в большинстве банков - 1- 0,1 копейки.
float - интересный тип. В DELPHI вроде real/double. А нормальный люди прописывают платёж в минимальных единицах (см выше).

← →
Fl@sh © (2006-03-18 00:51) [3]

> А нормальный люди прописывают платёж в минимальных единицах
> (см выше).

Да, но когда делаю инсерт данные сами дополняет мусором, а когда селект, так мне этот мусор нафиг не нужен!

← →
tesseract © (2006-03-18 12:19) [4]

> Да, но когда делаю инсерт данные сами дополняет мусором,

Мой - совет integer. больше скорость, меньше проблем. потом на 100 разделить можно.

← →
Гаврила © (2006-03-18 13:55) [5]

Ну или integer, или Currency

> Платежка, как ее отправлять, т.е. в каком виде. я
> думал просто делать insert на сервере, но данные ж
>придется шифровать,
> т.е. перед отправкой шифровать закритым ключом каждое
> поле, а при вставке разшифровка открытим, или лучще
> блоб поле шифровать, а потом разбирать что куда
> вставлять, как лучше сделать?

Как делал я:
на приеме входящих снаружи платежек сидела отдельная програма. Она расшифровывала, проверяла цифровую подпись, и уже потом выходила на коннект с сервером.
В базе это дело хранилось в виде блоба + некоторое дублирование для решения поисковых вопросов
(номер платедки, номер счета и еще что-то там дублировалось во полях таблицы, но живоне значение все равно бралось из блоба)

← →
LexxX © (2006-03-18 14:18) [6]

Товарищи, вы, собственно, о чем? Какие real/double и integer?!
Есть специальный тип данных для хранения денежных велечин, называется Currency или Numeric в зависимости от СУБД. Вот их и надо пользовать, а то integer/100 - это, простите меня, изврат!

← →
Гаврила © (2006-03-18 14:33) [7]

> LexxX ©

> а то integer/100 - это, простите меня, изврат!

Если делать совсем все правильно - то изврат.
А если предположить что все таки в ближайшие 20 лет рубль булет состоять из 100 копеек, а не из 10 или 1000 - то все жизненно

← →
Reindeer Moss Eater © (2006-03-18 14:39) [8]

Товарищи, вы, собственно, о чем? Какие real/double и integer?!

Товарищ, какой такой currency?
Речь идет о транспортном формате в котором платежный документ путешествует от клиента в банк.
Или предлагается *.gdb файлы использовать для обмена?

← →
Гаврила © (2006-03-18 14:51) [9]

> Reindeer Moss Eater ©

Очевидно, предполагается, что currency не стримится

← →
Reindeer Moss Eater © (2006-03-18 14:51) [10]

1. Платежка, как ее отправлять, т.е. в каком виде. я думал просто делать insert на сервере, но данные ж придется шифровать,
т.е. перед отправкой шифровать закритым ключом каждое поле, а при вставке разшифровка открытим, или лучще блоб поле шифровать, а потом разбирать что куда вставлять, как лучше сделать?

Исходный документ у клиента, на который накладывается ЭЦП, должен быть текстовым (Клиент должен видеть, что он подписывает).
Во время путешествия в банк этот подписанный документ или пакет документов должен быть зашифрован.
В банке документы расшифровываются и у них проверяется ЭЦП.
Если все в порядке, то документы в том виде в каком они приехали в банк и с неснятой ЭЦП должны быть сохранены в блобе as is.
Далее уже делается разбор транспортного формата и дальнейшие инсерты в таблицы документов (с рассовыванием атрибутов в отдельные поля таблиц) для последующей обработки системой или оператором.

← →
Fl@sh © (2006-03-18 18:44) [11]

Я не замечал у Firebierd currency. Посмотрю еще раз. Попробую с numeric.

← →
Fl@sh © (2006-03-18 18:50) [12]

> Reindeer Moss Eater © (18.03.06 14:51) [10]

Это то, что мне нужно. Буду делать по Вашей схеме. Спасибо.

← →
LexxX © (2006-03-18 19:04) [13]

Reindeer Moss Eater © (18.03.06 14:39) [8]
Товарищ, какой такой currency?
Речь идет о транспортном формате в котором платежный документ путешествует от клиента в банк.

Я отвечал вообще-то на следущее
Fl@sh © (17.03.06 22:19)
2. FireBird. Создал поле тип float, когда вставляю данные, например 100,12 мне добавляет еще левый мусор, т.е. 100,12435455, почему? как сделать, чтоб был формат 100,12 без мусора в конце. Или какой лучше тип

Внимательнее быть надо, однако...
:-/

← →
Fl@sh © (2006-03-19 12:31) [14]

> Гаврила © (18.03.06 13:55) [5]
>Как делал я:
> на приеме входящих снаружи платежек сидела отдельная програма.
> Она расшифровывала, проверяла цифровую подпись, и уже потом
> выходила на коннект с сервером.

Да, это был бы самый лучший вариант.
Но у меня с этим проблема. Я не работал с клиент сервером. Как например поставить на сервере прогу, точнее как сделать чтобы сначала с клиента данные проверялись на проге, а если ок, то расшифровка и запись в поля базы.
Как конектится к этой проге. Вообще не понимаю.
Можно линк где почитать.
У меня есть тайксер пачеко, разраб. в дельфи 5. Я не видел, или прохо искал.
Может есть готовый маленький пример.
Какими компонентами пользоваться?

← →
tesseract © (2006-03-19 12:56) [15]

> Да, это был бы самый лучший вариант.Но у меня с этим проблема.
> Я не работал с клиент сервером.

Смотри indy.
клиент-сервер может быть как TCP (желательно SSL). Так и telnet/ftp/smtp/imap.

главное чтобы данные дошли.

← →
Reindeer Moss Eater © (2006-03-19 14:38) [16]

Транспорт TCP/IP проще всего с точки зрения реализации системы.
SSL там лишнее звено, так как криптозащита все равно нужна и с помощью её же можно и прикладные данные протокола обмена защищать.
А вообще с точки зрения универсальности лучше смотреть в сторону HTTP.
Так как реальные клиенты почти всегда сидят за прокси-серверами. И часто на этих серверах ничего кроме http не разрешено (ни NAT, ни socks прокси)

← →
tesseract © (2006-03-19 14:57) [17]

> Транспорт TCP/IP проще всего с точки зрения реализации системы.

Ой не прав, проще всего - POP3/smtp. С шифрованным вложением.

там не надо головы ломать с протоколами. SSL звено ни фига не лишнее.

Ты абсолютно уверен, что сможешь сделать безглючную реализацию своего протокола?

> А вообще с точки зрения универсальности лучше смотреть в
> сторону HTTP.

А он здесь причём ему из клиентской проги надо данные пересылать.

← →
Reindeer Moss Eater © (2006-03-19 15:01) [18]

Ой не прав, проще всего - POP3/smtp. С шифрованным вложением.

Мы говорим про клиент-банк. Это вообще-то по определению онлайновый системы.

SSL звено ни фига не лишнее.

Лишнее. Почему - уже сказал.

Ты абсолютно уверен, что сможешь сделать безглючную реализацию своего протокола?

Без проблем.

А он здесь причём ему из клиентской проги надо данные пересылать.
В реальном мире клиенты сидят за прокси серверами. Очень часто это чистые HTTP прокси. Впрочем я уже говорил, зачем повторяться.

← →
tesseract © (2006-03-19 15:12) [19]

> Очень часто это чистые HTTP прокси. Впрочем я уже говорил,
> зачем повторяться.

как правило у них 100% рабочий mail.

Мне приходилось работать с многими клиент-банк системами.
Очень редко они работают on-line.
RSA/AES - довольно долго мучают бедные файлы.

Как правило бухгалтер подготавливает документы для отправки, а потом кипой сбрасывает в банк. Чаще всего используется SMTP/no-ralay. Т.Е. в подписи ставиться отправитель.

Известны примеры сразу нескольких вараинтов (TAXCOM - telnet/SMTP).

on-line в 100% случаях - это SSL. нигде не видел сайты где платежи проходят по чистому HTTP- это же дыра с тоннель под Ла-Маншем!

Самая безопасность - сбербанк. Там платёжки принимается только по прямому соединению с модемным пулом банка.

← →
Reindeer Moss Eater © (2006-03-19 15:17) [20]

Мне приходилось работать с многими клиент-банк системами.
Очень редко они работают on-line.

Мне приходилось разрабатывать такие системы. Все они работают в On Line.

on-line в 100% случаях - это SSL. нигде не видел сайты где платежи проходят по чистому HTTP- это же дыра с тоннель под Ла-Маншем!

Интересно, чем же http дырявее smtp?
И там и там используется tcp/ip. Прикладные данные зашифрованы.
В чем разница?

← →
Reindeer Moss Eater © (2006-03-19 15:32) [21]

Под использованием HTTP я конечно же не имел ввиду использование браузера как клиента.
Имелось ввиду использование http протокола как транспорта. Ввиду того, что его в реальном мире проксировать можно везде и всегда.

← →
DrPass © (2006-03-19 16:42) [22]

> Reindeer Moss Eater © (19.03.06 15:17) [20]

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

← →
Anatoly Podgoretsky © (2006-03-19 16:46) [23]

DrPass © (19.03.06 16:42) [22]
А ты не путай постоянную связь с клиент банком.

← →
DrPass © (2006-03-19 16:50) [24]

> Anatoly Podgoretsky © (19.03.06 16:46) [23]

Речь шла о работе в оффлайне или онлайне

← →
Reindeer Moss Eater © (2006-03-19 16:54) [25]

Онлайн не подразумевает постоянной связи с банком.
Под онлайном я подразумевал то, что имеется сеанс связи с банком.
Когда клиент напрямую соединяется с сервером. SMTP/POP это оффлайн.
Клиент посылает документы, которые когда-то то там скачает по поп3 банковская часть.
Оффлайновая часть клиента обязательно присутствует и в онлайновых системах. Документы готовятся и подписываются в любое время и даже разными пользователями. Связи с банком для этого не требуется.

По поводу использования почтовых протоколов могу рассказать следущее.
Когда-то давно, когда у меня уже был КБ, работающий по прямому модемному соединению, мне была поставлена задача реализовать сеансы через интернет. Так вот: первое, что мне тогда пришло в мою неокрепшую голову - это использование smtp/pop3. Буквально сразу, в течение первых трех секунд. К счастью, приоритет задаче выставили не самый высокий, и я успел понять, что решение это - просто дурацкое.
А если бы реализовал и внедрил его - то тоже бы наверное сейчас объяснял его соображениями безопастности и удобности, а не собственной дуростью.

Предлагать клиенту в 21 веке оффлайновый сервис - это издевательство над здравым смыслом. Типа нужна вам выписка - соединяйтесь с банком, оставляйте запрос и можете отключаться. За результатами зайдите позже.

← →
Anatoly Podgoretsky © (2006-03-19 16:58) [26]

DrPass © (19.03.06 16:50) [24]
Клиент банк начинается там, где начинается онлайн, а подготовка к этому может делать по разному.
Даже заполняя форму на интернет странице, мы это делаем в офлайн и только потом в онлайн посылаем ее на сервер.
Клиент банк подразумевает, что есть банк и есть клиентская программа, где мы подготавливаем данные и посылаем их в банк. Неважно когда и каким образом.

← →
Anatoly Podgoretsky © (2006-03-19 17:01) [27]

HTTP протокол не подразумевает постоянного соединения, каждый запрос устанавливает новое соединение. Все остальное ухищрения над этим.
На моем сайте есть книга по ИНДИ где это неплохо объяснено.

← →
Fl@sh © (2006-03-19 17:07) [28]

> Смотри indy.

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

Все верно.
Только у нас не настоящий веб-сервер и не настоящий веб-браузер.
Им ничто не мешает не рвать tcp соединение.
Ничто, кроме прокси серверов, ради которых все это собственно и затевалось.
Просто потребуется еще одно промежуточное звено.

Ася, например, по http работает исключительно из таких же соображений - выйти наружу через корпоративный прокси.

А это не важно, это определяет протокол. На протокол конечно можешь навернуть любые навороты, например sessionID

Есть разные варианты обмена. Среди каждого свои плюсы и минусы.

1. Стандартные протоколы.

- SMTP/POP3
Не гарантирует доставки. Следовательно, этот вариант можно отбросить.

Следовательно, остаются системы с прямым соединением.

Из них:

- FTP
Достаточно хороший вариант.

Плюс - протокол хорошо отлажен.
Минус - нет возможности организовать обмен в реальном режиме времени обмен подтверждениями(квитками).

- HTTP/HTTPS
Надежный вариант с прямым соединением с сервером в банке с возможностью обработки поступающих документов в реальном режиме времени. Полностью устраивает по всем параметрам.
Незначительный минус - дополнительное ПО в виде Web-сервера, что, в прочем, недостатком не будет в случае использования системы Интернет-Банк-Клиент.
--------------------
На остальных стандартных протоколах не имеет смысла останавливаться.

2. Нестандартные протоколы.

Под нестандартным протоколом подразумевается протокол обмена собственного производства.

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

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

Необходимость разработки транспортной системы пакетов своими силами для обслуживания десятков и сотен тысяч клиентов представляется весьма спорной. Для такой системы я ба предложил один из стандартных вариантов решения:

Back-офисное приложение(Сервер), Front-Офис(Интерфейс с клиентом), и между ними транспортное ПО. В качестве прослойки между ними может выступать как обычный Web-сервер, так и другие варианты ПО, предназначеные для решения подобных задач.
---------------

Для системы "Клиент-Банк" с небольшим объемом документов, проходящих через нее, выбор транспортной системы не очень принципиален, но мне решение с WEB-сервером нравится больше решения с собственным протоколом.

> - SMTP/POP3

Это, если не осуществляется непосредственное подключение клиента к серверу smtp провайдера. Так делает Taxcom например.

Вероятность недоставки письма в таком случае - 0,01 %.
Тем более что написав свой клиент/сервер можно высылать подтверждения о приёме/доставке.

> - FTP Достаточно хороший вариант.

Лучше всё-таки sFTP - он работает по SSL и не придётся навешивать свои защитные выкрутасы.

> Для системы "Клиент-Банк" с небольшим объемом документов,
> проходящих через нее, выбор транспортной системы не очень
> принципиален, но мне решение с WEB-сервером нравится больше
> решения с собственным протоколом.

Да Web-интерфейс удобнее. Но банки у нас весьма консервативны (особенно крупные). И часто считают wap/web небезопастным (и правильно делают)

Исчезает необходимость в клиентском ПО. Но оптимизировать сайт под современные браузеры, фишинг и другие приёмы - клиента написать всё-таки попроще.

Исчезает необходимость в клиентском ПО.

Это один большой и старый миф.

> tesseract © (19.03.06 18:28) [32]
> Это, если не осуществляется непосредственное подключение
> клиента к серверу smtp провайдера. Так делает Taxcom например.
> Вероятность недоставки письма в таком случае - 0,01 %.
> Тем более что написав свой клиент/сервер можно высылать
> подтверждения о приёме/доставке.

Абсолютно безразлично, к какому серверу подключаются клиент и банк.
Факт доставки от клиента в банк произойдет только тогда, когда серверная часть обработает письмо. Если же по каким-либо причинам письмо будет задерхано на SMTP-сервере, сей факт останется неизвестным достаточно продолжительное время. Что и будет являться не гарантированной доставкой.

> Лучше всё-таки sFTP - он работает по SSL и не придётся навешивать
> свои защитные выкрутасы.

Тоже без разницы. В любом случае, весь трафик обмена между клиентом и банком будет зашифрован. Причем намного более сильными средствами.

> Да Web-интерфейс удобнее. Но банки у нас весьма консервативны
> (особенно крупные). И часто считают wap/web небезопастным
> (и правильно делают)

Про WEB-интерфейс разговора не было. Я говорил про протокол HTTP.

> Reindeer Moss Eater © (19.03.06 19:18) [33]
>
> Исчезает необходимость в клиентском ПО.
>
> Это один большой и старый миф.

Ну почему же. Не будем же ActiveX считать клиентским ПО?

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

Я уже не говорю о такой мелочи, что у Васи с банком заключен договор на обсуживание, в котором оговорены детали защиты информации, выданы вполне определенные ключи и сертификаты с определенными алгоритмами.
А в Рио в том кафе их может и не быть.
Вася с собой будет возить инсталяцию криптопровайдера и просить админские права на компе в кафе что бы установить его?

> Reindeer Moss Eater © (19.03.06 19:53) [35]

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

В любом случае это наложит некоторые ограничения на использование.

Естественно, если в интернет-кафе запрещена загрузка ActiveX, то ничего не получится.

Криптопровайдер может быть и стандартным - майкрософтовским, который встроен в систему.

Все дело в том, какое решение выбрано банком.

В идеале достаточно электронного ключа на дискете.

А понятие "Клиентское ПО" я бы трактовал только как некое программное обеспечение, требующее установки и запуска по инициативе пользователя.
Т.е. запуск осуществляется именно клиентом-пользователем.

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

Сам по себе ключ - это кусок байтов. Он не может производить никаких криптографических преобразований. Нужна библиотека.

Криптопровайдер может быть и стандартным - майкрософтовским, который встроен в систему.

Встроен. Только попробуйте с помошью его подписать документ алгоритмом ГОСТ, про который он никогда ничего не слышал.
ГОСТ приведен только для примера. На том компьютере в кафе необязательно бкдет криптопровайдер, подддерживающий нужный вам алгоритм.

В идеале достаточно электронного ключа на дискете.
Про ключ я уже говорил. Его недостаточно.
Нужна криптобиблиотека или криптопровайдер.
Нужен сертификат, слепок отрытого ключа которого нарисован в договоре на обслуживание.

Итак, в случае чужого компьютера, миф о клиент-банке без клиента исчезает.
Если же клиент путешествует со своим ноутбуком, то вообще непонятен смысл фишки "не устанавливать клиентсокое ПО"

Reindeer Moss Eater © (19.03.06 21:00) [39]
Странно, а я постоянно пользуюсь и не подозревал, что нельзя, стандартный IE и ни каких дополнительных программ. Работаю с любого компьютера.
Вход возможен по таблице паролей, с помощью PIN калькулятора и с помощью card-reader, в который всовывается аналог паспорта.

Клиент Банк Найти похожие ветки