Ministerstwo Finansów

Podobne dokumenty
Ministerstwo Finansów

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP

Ogólnopolskie Repozytorium Prac Dyplomowych

Format danych adnotacji do tytułów wykonawczych przekazywanych do organów egzekucyjnych przez epuap w związku ze zbiegiem egzekucji

DOKUMENTACJA TECHNICZNA SMS API MT

Specyfikacja HTTP API. Wersja 1.6

Specyfikacja interfejsów usług Jednolitego Pliku Kontrolnego

Systemy internetowe. Wykład 5 Architektura WWW. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science

Gatesms.eu Mobilne Rozwiązania dla biznesu

Rola języka XML narzędziem

Specyfikacja techniczna. mprofi Interfejs API

Format danych adnotacji do tytułów wykonawczych przekazywanych do organów egzekucyjnych przez epuap w związku ze zbiegiem egzekucji

OPERATOR SYSTEMU PRZESYŁOWEGO

MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI

Dokumentacja SMS przez FTP

Języki programowania wysokiego poziomu WWW

Technologie internetowe

Dokumentacja REST API v 3.0. Kraków, 7 marca FreshMail, ul. Fabryczna 20a, Kraków tel , freshmail.

LAB 7. XML EXtensible Markup Language - Rozszerzalny Język Znaczników XSD XML Schema Definition Definicja Schematu XML

Regulamin Portalu Klienta Volkswagen Leasing GmbH Sp. z o.o. Oddział w Polsce ( Regulamin ) Definicje

Rozproszone systemy Internetowe

P R O C E D U R A P O D Ł Ą C Z E N I A S Y S T E M U D Z I E D Z I N O W E G O D O C S I Z S

Otwarte protokoły wymiany informacji w systemach ITS

Komunikacja i wymiana danych

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI

API transakcyjne BitMarket.pl

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Funkcje dodatkowe. Wersja 1.2.1

Świadczenie usługi hurtowej wysyłki wiadomości SMS dla Urzędu Miasta Torunia w latach

ZABEZPIECZENIE KOMUNIKACJI Z SYSTEMEM E-PŁATNOŚCI

Polityka prywatności i bezpieczeństwa przetwarzania danych osobowych w zbiorze czas-na-przeglad.pl

POLITYKA PRYWATNOŚCI ORAZ POLITYKA PLIKÓW COOKIES W Sowa finanse

Programowanie w Internecie

Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl

Specyfikacja wysyłek marketingowych v1.10

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP

API przekazy masowe - Dokumentacja. v 1.1, czerwiec 2014 KIP S.A. ul. Św. Marcin 73/ Poznań.

Nowa odsłona wyodrębnienie i kierunki jego rozwoju

Nowa odsłona wyodrębnienie i kierunki jego rozwoju Łysomice

Web Services. Wojciech Mazur. 17 marca Politechnika Wrocławska Wydział Informatyki i Zarządzania

Dokumentacja REST API v 3.0

Technologie sieciowe Sprawozdanie z labolatorium. Lista 5

Regulamin korzystania z systemu poczty elektronicznej Okręgowej Izby Radców Prawnych w Warszawie przez członków OIRP w Warszawie

Dokumentacja Techniczna 1.2. Webtoken MT. Uruchomienie subskrybcji MT poprzez serwis WWW

Szczegółowe informacje dotyczące przekazywania do Bankowego Funduszu Gwarancyjnego informacji kanałem teletransmisji

29. Poprawność składniowa i strukturalna dokumentu XML

DOKUMENTACJA INTERFEJSU API - HTTPS

Dokumentacja smsapi wersja 1.4

REGULAMIN PRZESYŁANIA FAKTUR W FORMIE ELEKTRONICZNEJ

Kurs walut. Specyfikacja projektu. Marek Zając

Integracja APD z Ogólnopolskim Repozytorium Prac Dyplomowych

Atrybuty SMS. Nazwa Twojej firmy lub produktu w SMS-ie podniesie prestiż Twojej wiadomości

Funkcje dodatkowe. Wersja 1.2.1

Programowanie komponentowe

Laboratorium nr 4 - Badanie protokołów WWW

Wszystko na temat wzoru dokumentu elektronicznego

1.2 Prawa dostępu - Role

wersja dokumentu 1.0 data wydania

Instrukcja użytkownika zewnętrznego systemu e-rpo wspierającego wdrażanie Regionalnego Programu Operacyjnego Województwa Małopolskiego na lata

Zasady Nazewnictwa. Dokumentów XML Strona 1 z 9

Bazy danych 2. Wykład 1

Korzystanie z Certyfikatów CC Signet w programie MS Outlook 98

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP

Seminarium epuap narzędziem nowoczesnej administracji. Sylwester Maślanka

Dokumentacja 2SMS

Instrukcja pobierania i weryfikacji zaświadczeń elektronicznych w portalu internetowym Polskiej Izby Inżynierów Budownictwa

Opis zmian funkcjonalności platformy E-GIODO wprowadzających możliwość podpisania wniosku bezpośrednio w oknie przeglądarki.

Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B

Warsztaty epuap. Administracja otwarta na obywatela. Kraków 2011 Arkadiusz Walewski, Zbigniew Olszak

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 2 SEAP SPECYFIKACJA XML INTERFEJS WEBSERVICE DLA PODMIOTÓW ZEWNĘTRZNYCH PL

POLITYKA PRYWATNOŚCI ORAZ ZASADY PRZETWARZANIA DANYCH OSOBOWYCH

Programowanie Komponentowe WebAPI

Sprawozdanie Sieci komputerowe i bazy danych Laboratorium nr 4

System DiLO. Opis interfejsu dostępowego v. 2.0

Warszawa, dnia 9 grudnia 2013 r. Poz. 1469

Nowa odsłona wyodrębnienie i kierunki jego rozwoju Międzyzdroje

Simple Object Access Protocol

Wybrane działy Informatyki Stosowanej

DPDInfoServices. Specyfikacja biznesowa. Version DPD Polska Sp. z O.O. Warszawa

Dokumentacja. Wersja: 1.5 Ostatnio zmodyfikowano: Strona 1

Dokumentacja interfejsu HTTPD. Platforma BSMS.PL Instrukcja podłączenia po przez http

GS2TelCOMM. Rozszerzenie do TelCOMM 2.0. Opracował: Michał Siatkowski Zatwierdził: IMIĘ I NAZWISKO

Krótka instrukcja instalacji

POLITYKA PRYWATNOŚCI SERWIS:

Serwery. Autorzy: Karol Czosnowski Mateusz Kaźmierczak

Instrukcja Użytkownika Systemu Zarządzania Tożsamością Wersja. 1.0

systemów intra- i internetowych Platformy softwarowe dla rozwoju Architektura Internetu (2) Plan prezentacji: Architektura Internetu (1)

Ministerstwo Finansów Departament Informatyzacji Usług Publicznych

Dokumentacja Techniczna SMS MO

Wymagania bezpieczeństwa wobec statycznych bezpośrednich 1-fazowych i 3-fazowych liczników energii elektrycznej. Wymaganie techniczne

Procedura Walidacyjna Interfejs

Proces obsługi deklaracji Intrastat w systemie Celina WebCel

INFRA. System Connector. Opis systemu

PUE ZUS Wysyłka elektronicznych zapytan. Instrukcja wysyłki zapytań do ZUZ-PUE za pomocą aplikacji Komornik SQL

INSTRUKCJA OBSŁUGI DLA SIECI

Dokumentacja REST API v 3.0

E-faktura instrukcja dla kontrahentów TVP S.A.

Gatesms.eu Mobilne Rozwiązania dla biznesu

Transkrypt:

Ministerstwo Finansów Departament Informatyzacji Rejestr Domen Służących do Oferowania Gier Hazardowych Niezgodnie z Ustawą Specyfikacja Wejścia-Wyjścia Wersja 1.1 Warszawa, 16.02.2017 r. Copyright (c) 2017 Ministerstwo Finansów MINISTERSTWO FINANSÓW, DEPARTAMENT INFORMATYZACJI ul. Świętokrzyska 12, 00-916 Warszawa http://www.mf.gov.pl www.hazard.mf.gov.pl e-mail: info.e-deklaracje@mf.gov.pl

Historia zmian dokumentu Nr Data wersji Autor zmiany Komentarz/Uwagi/Zakres zmian wersji 1.0 2017-02-15 MK Przygotowanie pierwszej wersji dokumentu 1.1 2017-03-22 MK Zmiany (dodanie wymagania zwrotu nagłówka Rsh-Push, informacje o retransmisji) i uszczegółowienie interfejsu PUSH, dodanie interfejsu do pobrania daty modyfikacji, opis wyrażenia regularnego, opis znaczenia pola Lp, odstęp między wywołaniem interfejsu PULL 1.2 2017-03-31 JK Dodano odcisk certyfikatu

Spis treści 1. Wprowadzenie... 4 1.1 Cel dokumentu... 4 1.2 Odbiorcy... 4 1.3 Definicje, Akronimy, Skróty... 4 2. Wstępne założenia interfejsów... 5 2.1 Metody komunikacji... 5 2.2 Schemat dokumentu XML... 5 3. Specyfikacja interfejsu do pobierania rejestru domen na żądanie... 7 3.1 Wstęp... 7 3.2 Opis interfejsu... 7 3.3 Odstęp między kolejnymi wywołaniami usługi... 8 3.4 Przykładowe żądanie i odpowiedź... 8 3.5 Uzyskiwanie informacji o czasie ostatniej modyfikacji... 9 4. Specyfikacja interfejsu odbierania danych o dodanej/wykreślonej domenie... 10 4.1 Wstęp... 10 4.2 Opis interfejsu... 10 4.3 Weryfikacja tożsamości nadawcy... 11 4.4 Przykładowe żądanie do interfejsu odbiorcy i odpowiedź... 11

1. Wprowadzenie 1.1 Cel dokumentu Celem dokumentu jest opisanie zasad komunikacji pomiędzy Rejestrem Domen Służących do Oferowania Gier Hazardowych Niezgodnie z Ustawą, a systemami operatorów, które potrzebują dostępu do informacji o domenach niezgodnych z obwiązującą ustawą hazardową. 1.2 Odbiorcy Dokument przygotowany został dla osób i firm z branży IT przygotowujących oprogramowanie do uzyskiwania informacji z Rejestru Domen Służących do Oferowania Gier Hazardowych Niezgodnie z Ustawą udostępnianego przez Ministerstwo Finansów. 1.3 Definicje, Akronimy, Skróty REST (ang. Representational state transfer) - styl architektury oprogramowania, który umożliwia dostęp i zarządzanie zasobami przy użyciu jednolitego i zdefiniowanego zbioru bezstanowych operacji. SSL - (ang. Secure Socket Layer) protokół aplikacyjny stosowany w celu zabezpieczenia poufności i integralności przesyłanych danych Standard opisany został na stronie http://wp.netscape.com/eng/ssl3. W3C (ang. The World Wide Web Consortium) - organizacja zajmująca się ustanawianiem standardów dla stron WWW. Publikowane przez W3C rekomendacje nie mają mocy prawnej, nakazującej ich użycie, lecz wskazują standardy dla rozwiązań technologicznych. XML - (ang. Extensible Markup Language, - Rozszerzalny Język Znaczników) to uniwersalny język formalny przeznaczony do reprezentowania różnych danych w ustrukturalizowany sposób. XML jest niezależny od platformy, co umożliwia łatwą wymianę dokumentów pomiędzy różnymi systemami i rekomendowany oraz specyfikowany przez organizację W3C. XSD (ang. XML Schema Definition - Schemat XML, Schemat Rozszerzalnego Języka Znaczników) to opracowany przez W3C standard służący do definiowania struktury dokumentu XML. Dokumenty zawierające definicje XML Schema zapisuje się zwykle w plikach z rozszerzeniem.xsd (od XML Schema Definition). Certyfikat kliencki certyfikat cyfrowy używany do uwierzytelnienia żądań do serwera. Używany w przypadku dwustronnego SSL (ang. 2-way SSL). Zapewnia potwierdzenie tożsamości wykonującego żądanie. Adres IP do przekierowań adres który należy przekierować próby połączenia się z domeną umieszczoną w Rejestrze Domen Służących do Oferowania Gier Hazardowych Niezgodnie z Ustawą: http://145.237.235.240/.

2. Wstępne założenia interfejsów 2.1 Metody komunikacji Udostępnione zostały dwie metody komunikacji mającej na celu uzyskanie informacji z Rejestru Domen Służących do Oferowania Gier Hazardowych Niezgodnie z Ustawą: Pobranie na żądanie (pull) odbiorca wywołuje usługę udostępnianą przez Ministerstwo Finansów i opisaną w niniejszym dokumencie. Odbiorca otrzymuje w ten sposób pełen spis blokowanych domen. Wypychanie danych (push) polega na przesyłaniu danych przyrostowo z Rejestru Domen Służących do Oferowania Gier Hazardowych Niezgodnie z Ustawą do interfejsu wystawionego przez obiorcę i zarejestrowanego na stronie. 2.2 Schemat dokumentu XML Do dokumentu został załączony plik XSD (Rejestr_v1-3.xsd). Dane zwracane/przesyłane przez Rejestr Stron Hazardowych (niezależnie od wybranej metody komunikacji) przejdą poprawnie walidację z załączonym schematem. 2.2.1 Graficzna reprezentacja schematu XML

Typ TAdresDomeny zawiera zdefiniowany wzorzec i wszystkie domeny dodawane do rejestru będą z nim zgodne. Wzorzec zakłada, że: Adres składa się z części oddzielonych znakiem kropki., Poszczególne części oprócz ostatniej mogą zawierać (wymagany minimum jeden znak) litery, cyfry oraz znak myślnika -, Znak myślnika nie może znajdować się bezpośrednio przed i po znaku kropki, Ostatni człon może zawierać tylko litery i musi zawierać minimum 2 znaki. Pole Lp wewnątrz elementu PozycjaRejestru jest jednoznacznym identyfikatorem wpisu w bazie rejestru. Jeśli poprzedni wpis dla danej domeny został zakończony, to w przyszłości może się pojawić również nowy wpis dla tej samej domeny, ale zawierający nowe Lp. Pole Lp może, więc służyć do rozróżnienia wpisów po stronie odbiorcy.

3. Specyfikacja interfejsu do pobierania rejestru domen na żądanie 3.1 Wstęp Opisywany interfejs umożliwia pobranie informacji znajdujących się w Rejestrze Domen Służących do Oferowania Gier Hazardowych Niezgodnie z Ustawą przez wywołanie usługi REST, która udostępniana jest przez protokół HTTPS. Zastosowanie usługi typu REST umożliwi sprawną integrację z rozwiązaniami klientów, niezależnie od technologii przez nich stosowanych. 3.2 Opis interfejsu Nazwa parametru Wartość Adres usługi https://hazard.mf.gov.pl/api/register Parametry przekazywane do wywołania usługi brak Typ metody GET Typ zwracanej zwartości application/xml Protokół HTTPS 3.2.1 Podstawowe parametry usługi Zwracany z usługi XML zawiera informacje o wszystkich blokowanych domenach w rejestrze oraz dacie i godzinie ich wpisania do rejestru. Z interfejsu na żądanie nie są zwracane informacje o wykreśleniach z rejestru. Jeśli domena nie znajduje się w odpowiedzi to znaczy, że nie jest blokowana. Odpowiedź z serwera zawiera kod odpowiedzi HTTP, który pozwoli zweryfikować poprawność wykonania operacji. Kod odpowiedzi serwera Opis 200 OK Poprawnie pobrano dane 400 Bad Request Błędne wywołanie usługi 405 Method Not Allowed Użyto niedopuszczalnego typu metody (np. POST) 406 Not Acceptable Response Nieakceptowalna odpowiedź. W przypadku, gdy system wywołujący usługę nie akceptuje application/xml 500 Server Error Błędne przetwarzanie zapytania 3.2.1 Niektóre możliwe kody odpowiedzi serwera

3.3 Odstęp między kolejnymi wywołaniami usługi W przypadku używania metody na żądanie do synchronizacji danych z rejestrem, zalecane jest wywoływanie usługi co dwie godziny. Podejrzanie zbyt częste wywoływanie metody może zostać uznane za atak i powodować zablokowanie dostępu z używanego adresu IP. 3.4 Przykładowe żądanie i odpowiedź GET https://www.hazard.mf.gov.pl/api/register HTTP/1.1 3.4.1 Żądanie pobrania rejestru blokowanych domen <?xml version="1.0" encoding="utf-8"?> <Rejestr xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns="http://www.hazard.mf.gov.pl/2017/03/21/" > <PozycjaRejestru Lp="1"> <AdresDomeny>domena2.pl</AdresDomeny> <DataWpisu>2017-02-10T10:44:00</DataWpisu> </PozycjaRejestru> <PozycjaRejestru Lp="2"> <AdresDomeny>domena3.pl</AdresDomeny> <DataWpisu>2017-02-13T10:44:00</DataWpisu> </PozycjaRejestru> <PozycjaRejestru Lp="3"> <AdresDomeny>domena4.pl</AdresDomeny> <DataWpisu>2017-02-14T10:44:00</DataWpisu> </PozycjaRejestru> </Rejestr> 3.4.2 XML zwracany w odpowiedzi na żądanie 3.3.1

3.5 Uzyskiwanie informacji o czasie ostatniej modyfikacji Istnieje możliwość pobrania czasu ostatniej modyfikacji rejestru bez pobierania całego rejestru. Nazwa parametru Wartość Adres usługi https://hazard.mf.gov.pl/api/register/modificationdate Parametry przekazywane do wywołania usługi brak Typ metody GET Typ zwracanej zwartości application/xml Protokół HTTPS 3.5.1 Podstawowe parametry usługi Kody odpowiedzi serwera zgodne są z tabelą 3.2.1. GET https://hazard.mf.gov.pl/api/register/modificationdate HTTP/1.1 3.5.1 Żądanie pobrania czasu ostatniej modyfikacji <?xml version="1.0" encoding="utf-8"?> <DataModyfikacji xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema">2017-03-22t12:17:39</datamodyfikacji> 3.5.2 XML zwracany w odpowiedzi na żądanie 3.5.1

4. Specyfikacja interfejsu odbierania danych o dodanej/wykreślonej domenie 4.1 Wstęp W celu zastosowania metody wypychania danych (push) odbiorca musi wystawić interfejs REST oparty na HTTPS, na który system Ministerstwa Finansów będzie przesyłał przyrostowo informacje o domenach. 4.2 Opis interfejsu Interfejs musi zostać zarejestrowany jako odbiorca na stronie hazard.mf.gov.pl. Przy rejestracji interfejsu zostanie wysłana informacja o obecnie blokowanych domenach. Wysyłka musi zakończyć się sukcesem, aby poprawnie zarejestrować interfejs. Do rejestracji odbiorcy wystarczający jest adres wystawionej usługi oraz kontaktowy adres email. Nazwa parametru Wartość Typ metody POST Typ danych przesyłanych do usługi application/xml Protokół HTTPS Wymagany nagłówek w odpowiedzi Rsh-Push o wartości accepted Wspierane protokoły bezpieczeństwa SSL3, TLS 1.0, TLS 1.1, TLS 1.2 Maksymalny czas trwania żądania 30 sekund 4.2.1 Definicja usługi wystawianej przez odbiorcę Akceptowane kody odpowiedzi interfejsu: 200 OK 201 Created 202 Accepted 204 No content Oprócz odpowiedniego kodu http, w odpowiedzi z interfejsu musi pojawić się nagłówek Rsh-Push o wartości accepted w ten sposób interfejs potwierdza, że chce otrzymywać informacje z systemu Ministerstwa Finansów. Brak nagłówka Rsh-Push zostanie uznany za niepoprawną wysyłkę. System Ministerstwa Finansów przesyła dane, które nie zostały wysłane jeszcze do interfejsu (jedna lub więcej pozycji). W tym celu porównywana jest data i godzina ostatniej poprawnej wysyłki do interfejsu oraz daty i godziny dodania/wykreślenia poszczególnych pozycji rejestru. W szczególności przy rejestracji interfejsu wysyłane są informacje o wszystkich obecnie blokowanych domenach.

System Ministerstwa Finansów stara się przesłać informacje przyrostowo wkrótce po dodaniu/wykreśleniu pozycji rejestru. W przypadku braku takiej możliwości, w szczególności gdy niedostępny jest interfejs odbiorcy system Ministerstwa Finansów będzie prowadził próby retransmisji brakujących danych co godzinę. Łącznie system będzie próbował przesyłać dane 48 razy (z godzinnymi odstępami). Jeśli w tym czasie nie uda się przeprowadzić poprawnej wysyłki to interfejs zostanie zablokowany i konieczny będzie kontakt z administratorem. 4.3 Weryfikacja tożsamości nadawcy Uwierzytelnienie dostawcy (systemu Ministerstwa Finansów) odbywa się na podstawie certyfikatu. System odbiorcy powinien sprawdzać zgodność certyfikatu klienckiego z załączonym certyfikatem systemu. Weryfikacja zgodności certyfikatu jest konieczna, aby upewnić się że dane o dodaniu/wykreśleniu domeny zostały faktycznie przesłane przez Ministerstwo Finansów. Odcisk certyfikatu to 69:6E:BA:DE:1E:49:CD:C1:EE:F8:80:1C:EB:E3:38:E4 4.4 Przykładowe żądanie do interfejsu odbiorcy i odpowiedź POST https://<receiver-domain>.pl/register HTTP/1.1 Content-Type: application/xml Content-Length: 372 <Rejestr xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns="http://www.hazard.mf.gov.pl/2017/03/21/"> <PozycjaRejestru Lp="1"> <AdresDomeny>domena2.pl</AdresDomeny> <DataWpisu>2017-02-10</DataWpisu> <DataWykreslenia>2017-02-13</DataWykreslenia> </PozycjaRejestru> </Rejestr> 4.4.1 Żądanie do interfejsu odbiorcy (może zawierać jedną lub więcej pozycji rejestru) HTTP/1.1 200 OK Conent-Length: 0 Rsh-Push: accepted Date: Wed, 22 Mar 2017 14:43:34 GMT 4.4.2 Przykładowa odpowiedź interfejsu odbiorcy