Gatesms.eu Mobilne Rozwiązania dla biznesu
|
|
- Julian Janik
- 9 lat temu
- Przeglądów:
Transkrypt
1 Mobilne Rozwiązania dla biznesu SPECYFIKACJA TECHNICZNA WEB API-USSD GATESMS.EU wersja 0.9 Opracował: Gatesms.eu
2 Spis Historia wersji dokumentu...3 Bezpieczeństwo...3 Wymagania ogólne...3 Mechanizm zabezpieczenia transmisji HTTP...3 Zasady ogóle...3 Definicja usług zdalnych...4 Zasada działania komunikacji z serwerem USSD...4 Informacje dodatkowe o usłudze...4 Nawiązywanie połączenia z serwerem USSD - rozpoczęcie sesji...4 Przykład żądania parametr body...4 Przykład odpowiedzi serwera...4 Komunikacja z aplikacją klienta...5 Nagłówki...5 Przykłady...5 Klasa obsługująca Web USSD Api...6 2/ 7
3 Historia wersji dokumentu wersja robocza Bezpieczeństwo Wymagania ogólne 1. Komunikacja w obu kierunkach musi uwzględniać zabezpieczenia transmisji HTTP opisane poniżej. Mechanizm zabezpieczenia transmisji HTTP Zabezpieczenia dla usług zdalnych dostępnych przez HTTP są niezależne od metody i formatu przesyłanych wiadomości Zasady ogóle Metody zdalne zwracają status http mniejszy niż 300 w przypadku, gdy operacja się powiedzie. Zwykle będą to statusy 200 lub 204. W przypadku, gdy operacja się nie powiedzie, usługa zwraca status błędu większy bądź równy 400. Dla uściślenia statusy od 400 włącznie do 500 wyłącznie oznaczają błąd w żądaniu (np. złe parametry - 400, błąd uwierzytelniania - 403, zły adres - 404). Statusy powyżej 500 włącznie oznaczają błąd po stronie serwera. Możliwe, że to samo żądanie po usunięciu usterki może zostać obsłużone poprawnie. Oznacza to, że dla statusów błędów poniżej 500 nie ma sensu ponawiać żądania, natomiast dla statusów od 500 włącznie, żądanie można ponawiać. Cele mechanizmu bezpieczeństwa: 1. Uwierzytelnienie klienta i serwera 2. Weryfikacja poprawności i prawdziwości żądania i odpowiedzi Serwer dla każdego klienta przygotowuje parę KeyID i SecretKey, gdzie KeyID jest identyfikatorem (jawnym, login podany w procesie rejestracji) a SecretKey jest kluczem ukrytym (hasło, 10 znaków). Aktualny tajny klucz można odczytać lub wygenerować po zalogowaniu w zakładce DANE UŻYTKOWNIKA. Obie te wartości są znane dla klienta i serwera. Uwierzytelnianie opiera się o dwa nagłówki HTTP dodawane do żądania i odpowiedzi. Dla żądania 1. X-GT-Timestamp - timestamp operacji (unix timestamp) 2. X-GT-Auth - dodatkowy nagłówek do uwierzytelniania. Przykład: X-GT-Auth: [KeyID]:[Hash] gdzie Hash to przygotowany skrót wiadomości opisany poniżej. X-GT-Auth: :098f6bcd4621d373cade4e832627b4f6. Hash = MD5(HTTP_method + URI_Path_Query + MD5_Body + Accept + X-GT-Timestamp + SecretKey) Gdzie MD5 to funkcja haszująca a '+' oznacza konkatenację łańcuchów znaków oraz: Przykład: 1. HTTP_method to GET, POST, PUT itp. 2. URI_Path_Query to ścieżka i query string czyli część URL'a od pierwszego znaku '/' np: /ussd_api.php 3. MD5_Body - to MD5 z treści żądania o ile jest 4. Accept - nagłówek określający format odpowiedzi (zgodny ze standardem), przyjmuje wartości np. application/xml 5. X-GT-Timestamp - timestamp wykonania operacji (taki jak w nagłówku) 6. SecretKey - klucz klienta MD5(POST/ussd_api.phpZXQW345YULAccept:application/xml LQBwxTiDnv) 3/ 7
4 Strona odbierająca żądanie ma obowiązek sprawdzenia, czy Hash jest poprawny. Jeśli nie jest to powinien zostać zwrócony status 403. Dla odpowiedzi Hash = MD5(MD5_Body + Content-Type + X-GT-Timestamp + SecretKey) gdzie SecretKey to klucz klienta, od którego otrzymaliśmy wiadomość Przykład MD5(9843f33LQd8xTiDnvGAKoc8n7pQ5qi3CW9SG584ContentType:application/xml LQBwxTiDnv) Klient otrzymujący odpowiedź od serwera ma obowiązek sprawdzenia, czy odpowiedź jest podpisana poprawnie o ile żądanie zostało poprawnie obsłużone. Odpowiedzi o statusach >= 400 nie muszą być podpisane. W przypadku błędu komunikaty błędów mogę być zamieszczone w odpowiedzi HTTP jako tekst. Definicja usług zdalnych Do transmisji danych wykorzystywany będzie głównie format XML. Obie strony mają obowiązek zapewnić zgodność przesyłanych dokumentów ze standardem XML. Dotyczy to w szczególności zasad używania znaków specjalnych w wiadomościach. Dokument XML przesyłany jest metodą POST. Nagłówki Accept i Content-Type muszą być poprawnie ustawione, np.: Content-Type: application/xml Accept: application/xml Zasada działania komunikacji z serwerem USSD Zainicjowanie sesji z usługą leży po stronie klienta. Klient nawiązując połączenie z serwerem przekazuje podstawowe parametry potrzebne do zainicjowania sesji. Po zainicjowaniu sesji serwer USSD komunikuje się z usługą zdalną za pomocą protokołu HTTP z żądaniem podania listy instrukcji(menu). Usługa zdalna odpowiada a serwer USSD przekazuje informację pod wskazany numer MSISDN. Cała sesja trwa aż do zakończenia przez usługę inicjującą lub przez usługę zdalną. Informacje dodatkowe o usłudze Długość wiadomości przy kodowaniu GSM7 wynosi 182 znaki a wiadomości kodowane w UCS2 mają maksymalną długość 66 znaków. Nawiązywanie połączenia z serwerem USSD - rozpoczęcie sesji Adres usługi : Metoda : POST Content-Type: application/xml Accept: application/xml Przykład żądania parametr body <?xml version="1.0" encoding="utf-8" standalone="yes"?> <session prefix="index1" msisdn=" " language="gsm-7" >START</session> Przykład odpowiedzi serwera <?xml version="1.0" encoding="utf-8" standalone="yes"?><session>start OK</session> 4/ 7
5 Element session: Atrybuty obowiązkowe prefix - unikalny identyfikator usługi klienta msisdn - numer komórkowy z którym będzie prowadzona korespondencja language - kodowanie, może przyjąć wartości GSM-7 lub UCS-2 Komunikacja z aplikacją klienta Po poprawnym nawiązaniu sesji z serwerem USSD, serwer nawiązuje połączenie z aplikacją kliencką wysyłając do niej żądania podania instrukcji (menu). Definicja adresu zdalnej usługi konfigurowana jest po zalogowaniu do systemu w zakładce SMS -> USSD. Należy podać prefix oraz adres do usługi. Serwer USSD komunikuje się z usługą zdalną (klient) wysyłając nagłówki oraz treść dokumentu xml. Metoda: POST Content-Type: application/x-www-form-urlencoded Accept: application/xml Nagłówki X-GT-Session: (String) - identyfikator sesji X-GT-Action: (String) start - wysyłany przy inicjowaniu sesji, wysyłany jako pierwszy komunikat reponse - wysyłany w trakcie trwania sesji stop - wysyłany do klienta aby zakończył sesję. Przykłady Nagłówek: X-GT-Action: start <?xml version="1.0" encoding="utf-8" standalone="yes"?><session msisdn=" ">abcd1234</session> <?xml version="1.0" encoding="utf-8" standalone="yes"?> <ussdmenu shouldclose="false" msisdn=" ">dobry program\n1 - TAK\n2 - NIE</ussdmenu> Element ussdmenu: Atrybuty obowiązkowe shouldclose - atrybut informuje czy nadawany komunikat jest ostatnim i transmisja powinna zosta ć zakończna msisdn - numer komórkowy Nagłówek: X-GT-Action: status <?xml version="1.0" encoding="utf-8" standalone="yes"?><session msisdn=" ">abcd1234</session> <?xml version="1.0" encoding="utf-8" standalone="yes"?><session isactive="true" msisdn=" ">abcd1234</session> Element session: Atrybuty obowiązkowe isactive - atrybut informuje czy aktualna sesja nadal jest potrzymywana przez aplikacj ę klienta msisdn - numer komórkowy Nagłówek: X-GT-Action: response <?xml version="1.0" encoding="utf-8" standalone="yes"?> <session msisdn=" "><text>1</text></session> <?xml version="1.0" encoding="utf-8" standalone="yes"?> <ussdmenu shouldclose="true" msisdn=" ">do zobaczenia.</ussdmenu> 5/ 7
6 Nagłówek: X-GT-Action: stop <?xml version="1.0" encoding="utf-8" standalone="yes"?><session>end</session> <?xml version="1.0" encoding="utf-8" standalone="yes"?><session>end OK</session> Dodatek A Klasa obsługująca Web USSD Api Przykład obsługi klasy USSD_CLIENT z pliku ussd_client.php Przykładowy plik workflow.php Struktura plików źródłowych ussd/ ->session/ ->Session.php ->data/ ->http_request.php ->sms_xmlsender.php -> ussd_client.php ->workflow/ ->workflow1.php ->client/ ->trigger.php <? include '../session/session.php'; include '../data/ussd_client.php'; include '../data/sms_xmlsender.php'; include '../data/http_request.php'; //REQUEST $http_request = new http_request(); //SESJA $sessionid=$http_request->headers["x-gt-session"]; //ID SESJI $session = new Session($sessionID); $Workflow=$session->getWorkflow( $sessionid ); if($workflow) { $ussd=$workflow; } else { //Konstruktor klasy, oraz parametry $ussd = new USSD_CLIENT; $ussd->login=" "; $ussd->pass="0c27ab3d03"; $ussd->debug=0; //LOGOWANIE $Hash_serv=$ussd->serverLogin($http_request); //ZADANIA $XML=$ussd->parserXML($http_request->body); // if($http_request->headers["x-gt-action"]=='status') { $Workflow=$session->getWorkflow( $sessionid ); $isactive = ($Workflow)? 'true' : 'false'; $out=$ussd->getstats($isactive,$sessionid); } 6/ 7
7 ?> if($http_request->headers["x-gt-action"]=='start') { $ussd->shouldclose='false'; $ussd->requestcount=1; $ussd->menu="twoje pierwsze menu testowe.\\n1 - Zakoncz"; $out=$ussd->getmenu(); $session->savesession( $sessionid, $ussd ); if($http_request->headers["x-gt-action"]=='response') { if($ussd->text=='1' && $ussd->requestcount==1) { $ussd->shouldclose='true'; $ussd->requestcount++; $ussd->menu="usluga dziala poprawnie"; $out=$ussd->getmenu(); } $session->savesession( $sessionid, $ussd ); if($http_request->headers["x-gt-action"]=='stop') { $out=$ussd->closesession(); $session->removeworkflow( $sessionid ); $ussd->toout($out); exit; 7/ 7
Gatesms.eu Mobilne Rozwiązania dla biznesu
SPECYFIKACJA TECHNICZNA WEB XML-API GATESMS.EU wersja 1.2 Gatesms.eu Spis Historia wersji dokumentu... 3 Bezpieczeństwo... 3 Wymagania ogólne... 3 Mechanizm zabezpieczenia transmisji HTTP...3 Zasady ogóle...
Dokumentacja Techniczna 1.2. Webtoken MT. Uruchomienie subskrybcji MT poprzez serwis WWW
Dokumentacja Techniczna 1.2 Webtoken MT Uruchomienie subskrybcji MT poprzez serwis WWW CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42 Fax: +48 032 764-18-40 Infolinia:
Dokumentacja interfejsu HTTPD. Platforma BSMS.PL Instrukcja podłączenia po przez http
Dokumentacja interfejsu HTTPD Platforma BSMS.PL Instrukcja podłączenia po przez http Dokumentacja interfejsu httpd (strona 2) SPIS TREŚCI 1. Zawartość dokumentu str.3 2. Informacje ogólne 2.1 Zastosowanie
Specyfikacja HTTP API. Wersja 1.6
Specyfikacja HTTP API Wersja 1.6 1. Wprowadzenie Platforma PlaySMS umożliwia masową rozsyłkę SMS-ów oraz MMS-ów marketingowych. Umożliwiamy integrację naszej platformy z dowolnym systemem komputerowym
Specyfikacja wysyłek marketingowych v1.10
Specyfikacja wysyłek marketingowych v1.10 1 Historia zmian: Al. Jerozolimskie 81 Data Autor Opis 05-07-2013 Olga Krygier-Zawistowska Dodano przykład w PHP 2 Specyfikacja komunikacji Al. Jerozolimskie 81
Specyfikacja interfejsów usług Jednolitego Pliku Kontrolnego
a. Specyfikacja interfejsów usług Jednolitego Pliku Kontrolnego Ministerstwo Finansów Departament Informatyzacji 23 May 2016 Version 1.3 i Spis treści 1 Przygotowanie danych JPK... 3 1.1 Przygotowanie
OPIS TECHNICZNY SYSTEM HOSTED SMS
OPIS TECHNICZNY SYSTEM HOSTED SMS Wersja 1.6.2 Warszawa, lipiec 2015 1 SPIS TREŚCI 1. Wprowadzenie... 3 2. Podstawowe Parametry systemu Hosted SMS... 3 Dostępność... 3 Definicja znaków i długości wiadomości
DOKUMENTACJA TECHNICZNA KurJerzyAPI wersja 1.0
KurJerzyAPI wersja 1.0 Spis treści Wstęp...3 1. Korzystanie z interfejsu KurJerzyAPI...4 1.1 Warunki korzystania z interfejsu...4 1.2 Zabezpieczenia interfejsu...4 2. Specyfikacja interfejsu KurJerzyAPI...6
System DiLO. Opis interfejsu dostępowego v. 2.0
System DiLO Opis interfejsu dostępowego v. 2.0 Warszawa 2015 1 Wprowadzone zmiany Wersja Opis 1.0 Wersja bazowa 1.1 Dodanie możliwości przejścia z wydania karty w POZ (WK-POZ) do zabiegu operacyjnego (ZAB-OPER)
Płatności CashBill - SOAP
Dokumentacja techniczna 1.0 Płatności CashBill - SOAP Dokumentacja wdrożenia systemu Płatności CashBill w oparciu o komunikację według protokołu SOAP CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa
API transakcyjne BitMarket.pl
API transakcyjne BitMarket.pl Wersja 20140402 1. Sposób łączenia się z API... 2 1.1. Klucze API... 2 1.2. Podpisywanie wiadomości... 2 1.3. Parametr tonce... 2 1.4. Limity zapytań... 3 1.5. Odpowiedzi
Ogólnopolskie Repozytorium Prac Dyplomowych
Ogólnopolskie Repozytorium Prac Dyplomowych System Informacji o Szkolnictwie Wyższym POL-on Źródła danych i sposób zasilania, formaty i aspekty organizacyjne Strona 1 z 8 Spis treści Spis treści 1.Źródła
Programowanie komponentowe. Przykład 1 Bezpieczeństwo wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz
Programowanie komponentowe Przykład 1 Bezpieczeństwo wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz Struktura wykładu 1. Utworzenie użytkowników i ról na serwerze aplikacji Sun Java System Application
DOKUMENTACJA TECHNICZNA SMS API MT
DOKUMENTACJA TECHNICZNA SMS API MT Mobitex Telecom Sp.j., ul. Warszawska 10b, 05-119 Legionowo Strona 1 z 5 Ten dokument zawiera szczegółowe informacje odnośnie sposobu przesyłania requestów do serwerów
Dokumentacja techniczna API systemu SimPay.pl
Wprowadzenie Dokumentacja techniczna API systemu SimPay.pl Wersja 1.0 z dnia 24.03.2015 r. API serwisu SimPay.pl opiera się o danych wysyłanych i zwracanych w formie JSON. W przypadku napotkania jakiegokolwiek
Spis treści INTERFEJS (WEBSERVICES) - DOKUMENTACJA TECHNICZNA 1
I N T E R F E J S W E BSERVICES NADAWANIE PAKIETÓW D O S Y S T EMU MKP PRZEZ I N TERNET D O K U M E N T A C J A T E C H N I C Z N A P A Ź D Z I E R N I K 2 0 1 6 Spis treści 1. Wstęp... 2 2. Informacje
Implementacja mechanizmu SkyCashClick Wersja 0.1
Implementacja mechanizmu SkyCashClick Wersja 0.1 SkyCash 1/6 Spis treści: 1. Opis usługi... 3 2. Osadzenie przycisku SkyCashClick... 4 2.1. Parametry transakcji... 4 2.2. Weryfikacja znacznika parametrów
Podręcznik Integracji
Podręcznik Integracji Spis treści 1. Integracja oferty... 3 1.1. Samodzielne wprowadzanie oferty sklepu... 3 1.2. Automatyczne wprowadzanie oferty z pliku XML... 3 1.3. Cyklicznie pobieranie oferty ze
Specyfikacja API 1.0. Specyfikacja kontroli Konta systemu CashBill z wykorzystaniem API opartego na REST
Specyfikacja API 1.0 API REST Specyfikacja kontroli Konta systemu CashBill z wykorzystaniem API opartego na REST CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42
Automater.pl zdalne tworzenie i zarządzanie transakcjami dokumentacja API wersja 0.1
Dokumentacja API 0.1 Automater.pl zdalne tworze i zarządza transakcjami dokumentacja API wersja 0.1 Automater sp. z o.o., ul. Belgradzka 4/42, 02-793 Warszawa 2 1. Wstęp System Automater.pl udostępnia
Dokumentacja Techniczna. Dokumentacja techniczna usługi płatności mobilnych
Dokumentacja Techniczna 1.3, beta Direct Billing Dokumentacja techniczna usługi płatności mobilnych CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42 Fax: +48 032
Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl
Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl wersja.2.9 data 2014-11-21 Opis usług: P24 KOD P24 KLUCZ P24 WAPA SEND SMS Strona 1 z 8 P24 KOD Przebieg transakcji Operacje po stronie Sprzedawcy
Połączenie Partnera z serwisem JustPay poprzez - METODĘ 2
Połączenie Partnera z serwisem JustPay poprzez - METODĘ 2 Generowanie kodów: po stronie Partnera Weryfikacja kodów: po stronie Partnera Spis treści 1. Kolejne kroki w stworzeniu własnego serwisu 2. Jak
ZABEZPIECZENIE KOMUNIKACJI Z SYSTEMEM E-PŁATNOŚCI
PROJEKT: ZAPROJEKTOWANIE, WYKONANIE I WDROŻENIE SYSTEMU INFORMATYCZNEGO OBSŁUGUJĄCEGO E-PŁATNOŚCI ZABEZPIECZENIE KOMUNIKACJI Z SYSTEMEM E-PŁATNOŚCI Strona 1 z 19 Informacje o Historia zmian Wprowadzenie
DOKUMENTACJA INTERFEJSU API - HTTPS
DOKUMENTACJA INTERFEJSU API - HTTPS WERSJA 0.1 DATA PUBLIKACJI : 01.03.2014 SPIS TREŚCI Spis treści Wprowadzenie 1 Dostęp do usługi notowania online 2 Opis struktur danych 3 Kody błędów 5 Historia wersji
Wykład 4. Metody uwierzytelniania - Bezpieczeństwo (3) wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz
Wykład 4 Metody uwierzytelniania - Bezpieczeństwo (3) wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz Struktura wykładu 1. Protokół SSL do zabezpieczenia aplikacji na poziomie protokołu transportowego
Wykład 3 Inżynieria oprogramowania. Przykład 1 Bezpieczeństwo(2) wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz
Wykład 3 Inżynieria oprogramowania Przykład 1 Bezpieczeństwo(2) wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz Struktura wykładu 1. Utworzenie użytkowników i ról na serwerze aplikacji Sun Java System
Dokumentacja serwera REST do obsługi rezerwacji w systemie SaNAtoRIUm.pro
Dokumentacja serwera REST do obsługi rezerwacji w systemie SaNAtoRIUm.pro Kontakt: tel. 54 282 1385 e-mail: info@softor.pl Podstawowe informacje: Serwer REST dostępny pod adresem https://api.sanatorium.pro/v1/
Systemy internetowe. Wykład 3 PHP. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science
Systemy internetowe Wykład 3 PHP PHP - cechy PHP (Hypertext Preprocessor) bardzo łatwy do opanowania, prosta składnia, obsługuje wymianę danych z różnymi systemami baz danych pozwala na dynamiczne generowanie
Dokumentacja REST API v 3.0. Kraków, 7 marca FreshMail, ul. Fabryczna 20a, Kraków tel , freshmail.
Dokumentacja REST API v 3.0 Kraków, 7 marca 2012 FreshMail, ul. Fabryczna 20a, 31-553 Kraków tel. +48 12 617 61 40, info@freshmail.pl, freshmail.pl Wersja dokumentu: 1.0 Autorzy: Tadeusz Kania ,
Dokumentacja REST API v 3.0
Dokumentacja REST API v 3.0 Kraków, 16 kwietnia 2012 FreshMail, ul. Fabryczna 20a, 31-553 Kraków tel. +48 12 617 61 40, info@freshmail.pl, freshmail.pl Spis treści Opis API... 3 Uwierzytelnienie... 3 Odpowiedzi
Specyfikacja techniczna. mprofi Interfejs API
Warszawa 09.04.2015. Specyfikacja techniczna mprofi Interfejs API wersja 1.0.2 1 Specyfikacja techniczna mprofi Interfejs API wersja 1.0.2 WERSJA DATA STATUTS AUTOR 1.0.0 10.03.2015 UTWORZENIE DOKUMENTU
Sesje i logowanie. 1. Wprowadzenie
Sesje i logowanie 1. Wprowadzenie Żądania od nawet tego samego użytkownika na serwerze nie są domyślnie w żaden sposób łączone ze sobą. Każde jest w pewnym sensie nowe i serwer nie jest w stanie stwierdzić,
Dokumentacja techniczna SMS MO
Dokumentacja techniczna SMS MO Spis Treści 1. Wprowadzenie 2 1.1. Przebieg płatności Premium SMS 2 1.2. Weryfikacja płatności..3 2. Weryfikacja poprawności kodu aktywacyjnego...3 3. Przykład użycia zapytania
Ministerstwo Finansów
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)
SSL (Secure Socket Layer)
SSL --- Secure Socket Layer --- protokół bezpiecznej komunikacji między klientem a serwerem, stworzony przez Netscape. SSL w założeniu jest podkładką pod istniejące protokoły, takie jak HTTP, FTP, SMTP,
Silne uwierzytelnianie dla klienta indywidualnego
BANK SPÓŁDZIELCZY W ŚLESINIE Silne uwierzytelnianie dla klienta indywidualnego (instrukcja użytkownika) Wersja 22.2 https://www.online.bsslesin.pl Silne uwierzytelnienie Klienta Silne uwierzytelnienie
Funkcje dodatkowe. Wersja 1.2.1
Funkcje dodatkowe Wersja 1..1 Dokumentacja SMSAPI (https) FUNKCJE DODATKOWE z dnia 1.06.01 Wersja 1..1 SPIS TREŚCI 1.Wprowadzenie 1.1 Adresy URL do połączenia z aplikacją dla funkcji zarządzania kontem
BRAMKA HTTP SMS XML Dokumentacja techniczna. wersja 3.32
BRAMKA HTTP SMS XML Dokumentacja techniczna wersja 3.32 autor: Michał Jastrzębski ostatnia aktualizacja : 27.05.2015 Historia zmian Data Osoba Opis zmian 2006-12-01 Marcin Mańk Pierwsza wersja 2007-08-20
Spis treści 1. Założenia ogólne 2. Wymagania 3. Typy SMSów 4. Statusy SMSów 5. Wysyłanie SMSów - Web API 6. Wysyłanie SMSów - Email 7.
V 1.1 2008 Spis treści 1. Założenia ogólne 2. Wymagania 3. Typy SMSów 4. Statusy SMSów 5. Wysyłanie SMSów - Web API 6. Wysyłanie SMSów - Email 7. Sprawdzanie stanu konta 1. Założenia ogólne PowiadomieniaSMS.pl
Dokumentacja SMS przez FTP
Dokumentacja SMS przez FTP 1 Wprowadzenie... 2 Właściwości plików... 3 Tworzenie konfiguracji w Panelu Klienta... 4 Raporty doręczeń... 5 Historia zmian... 6 2 Wprowadzenie Usługa wysyłki SMS przez FTP
Systemy internetowe. Wykład 5 Architektura WWW. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science
Systemy internetowe Wykład 5 Architektura WWW Architektura WWW Serwer to program, który: Obsługuje repozytorium dokumentów Udostępnia dokumenty klientom Komunikacja: protokół HTTP Warstwa klienta HTTP
DirectBilling dokumentacja techniczna
CashBill S.A. DirectBilling: dokumentacja techniczna 1/11 DirectBilling dokumentacja techniczna status: BETA, v1.2 CashBill S.A. DirectBilling: dokumentacja techniczna 2/11 Historia zmian autor data zmiany
Dokumentacja smsapi wersja 1.4
Dokumentacja smsapi wersja 1.4 1. Wprowadzenie Platforma smsapi została skierowana do użytkowników chcących rozbudować swoje aplikacje o system wysyłania smsów. Aplikacja ta w prosty sposób umożliwia integrację
Aktualizacja SMSFall v. 1.1.5 Data publikacji: 20-05-2013
Aktualizacja SMSFall v. 1.1.5 Data publikacji: 20-05-2013 Wersja Standard i Plus: we właściwościach terminala dodano wskaźnik poziomu sygnału urządzenia GSM wyrażony w dbm. Podstawa teoretyczna: http://pl.wikipedia.org/wiki/dbm.
Sprawozdanie nr 4. Ewa Wojtanowska
Sprawozdanie nr 4 Ewa Wojtanowska Zad.1 Korzystając z zasobów internetu zapoznałam się z dokumentami: RFC 1945 i RFC 2616. Zad.2 Badanie działania protokołu http Zad.3 Zad.4 URL (ang. Uniform Resource
DOKUMENTACJA PROTOKOŁU SMESX. Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS Protokół w wersji 2.2
DOKUMENTACJA PROTOKOŁU SMESX Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS Protokół w wersji 2.2 Autor smeskom@smeskom.pl Data 16.06.2009 Wersja 2.2 (rev. 1) Spis treści Dokumentacja protokołu
DPDInfoServices. Specyfikacja biznesowa. Version DPD Polska Sp. z O.O. Warszawa
DPDInfoServices Specyfikacja biznesowa Version 1.0.7 2015-02-06 DPD Polska Sp. z O.O. Warszawa Spis treści 1 Historia dokumentu... 3 2 Wstęp... 4 3 Bezpieczeństwo przesyłanych danych... 4 4 Konfiguracja
Wykład 4. komputerowych Protokoły SSL i TLS główne slajdy. 26 października 2011. Igor T. Podolak Instytut Informatyki Uniwersytet Jagielloński
Wykład 4 Protokoły SSL i TLS główne slajdy 26 października 2011 Instytut Informatyki Uniwersytet Jagielloński 4.1 Secure Sockets Layer i Transport Layer Security SSL zaproponowany przez Netscape w 1994
Kontrola sesji w PHP HTTP jest protokołem bezstanowym (ang. stateless) nie utrzymuje stanu między dwoma transakcjami. Kontrola sesji służy do
Sesje i ciasteczka Kontrola sesji w PHP HTTP jest protokołem bezstanowym (ang. stateless) nie utrzymuje stanu między dwoma transakcjami. Kontrola sesji służy do śledzenia użytkownika podczas jednej sesji
HttpRequest Aplikacja Czat
HttpRequest Aplikacja Czat Za pomocą obiektu HttpRequest można wykonywać żądania http z aplikacji windows phone. W pierwszej kolejności należy utworzyć aplikację i dodać do niej dwie kontrolki: Buton i
Subskrypcje MT (płatność za otrzymany SMS)
Subskrypcje MT (płatność za otrzymany SMS) Uruchomienie subskrypcji umożliwia tworzenie serwisów, gdzie Użytkownik płaci za każdy odebrany SMS. Każdy serwis ma zdefiniowany wcześniej dni i godziny kiedy
Dokumentacja interfejsu MySQL. Platforma BSMS.PL Instrukcja podłączenia po przez mysql
Dokumentacja interfejsu MySQL Platforma BSMS.PL Instrukcja podłączenia po przez mysql Dokumentacja interfejsu mysql (strona 2) SPIS TREŚCI 1. Zawartość dokumentu str.3 2. Informacje ogólne 2.1 Zastosowanie
SMS Kod Automatyczny
Dokumentacja 2.0.0 SMS Kod Automatyczny Dokumentacja dla SMS Kod Automatyczny Web Service REST CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42 Fax: +48 032 764-18-40
Specyfikacja Techniczna 2.0. Specyfikacja techniczna usługi dystrybucji kodów dostępowych PayCode
Specyfikacja Techniczna 2.0 PayCode API Specyfikacja techniczna usługi dystrybucji kodów dostępowych PayCode CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42 Fax:
Specyfikacja API bramki SMS/MMS/TTS
Specyfikacja API bramki SMS/MMS/TTS wersja 1.3.1 Piotr Isajew (pki@ex.com.pl) 21 lutego 2011 c 2011 EXPERTUS, http://www.ex.com.pl 1. Wprowadzenie API działa w oparciu o proste komunikaty XML przekazywane
API przekazy masowe - Dokumentacja. v 1.1, czerwiec 2014 KIP S.A. ul. Św. Marcin 73/ Poznań.
API przekazy masowe - Dokumentacja v 1.1, czerwiec 2014 KIP S.A. ul. Św. Marcin 73/6 61-808 Poznań www.kipsa.pl www.tpay.com 1 Bramka API Dokumentacja opisuje możliwość wykonania przekazów masowych za
Ministerstwo Finansów
Ministerstwo Finansów Departament Informatyzacji Specyfikacja Wejścia-Wyjścia Wersja 1.0 Warszawa, 16.02.2017 r. Copyright (c) 2017 Ministerstwo Finansów MINISTERSTWO FINANSÓW, DEPARTAMENT INFORMATYZACJI
PolishAPI. Rekomendacje oraz podstawowe założenia do przygotowania interfejsu awaryjnego. Dokument opracowany przez Grupę Projektową ds.
PolishAPI Rekomendacje oraz podstawowe założenia do przygotowania interfejsu awaryjnego Dokument opracowany przez Grupę Projektową ds. PolishAPI 8 lipca 2019 Wersja 1.0 Spis treści 1 Wstęp i zastrzeżenia...
Jarosław Kuchta Administrowanie Systemami Komputerowymi. Internetowe Usługi Informacyjne
Jarosław Kuchta Internetowe Usługi Informacyjne Komponenty IIS HTTP.SYS serwer HTTP zarządzanie połączeniami TCP/IP buforowanie odpowiedzi obsługa QoS (Quality of Service) obsługa plików dziennika IIS
Systemy internetowe Wykład 3 PHP
Systemy internetowe Wykład 3 PHP PHP - cechy PHP (Hypertext Preprocessor) bardzo łatwy do opanowania, prosta składnia, obsługuje wymianę danych z różnymi systemami baz danych pozwala na dynamiczne generowanie
INFAKT API - opis (ver. 0.8)
INFAKT API - opis (ver. 0.8) 1. Autoryzacja Autoryzacja odbywa się poprzez Basic Authorization dzięki danym dostępowym do serwisu infakt.pl Oprócz tych danych należy wygenerować klucz do API na stronie
Instrukcja logowania do systemu Rejestru Unii dla nowych użytkowników
Instrukcja logowania do systemu Rejestru Unii dla nowych użytkowników Przed pierwszym logowaniem do Rejestru Unii należy dokonać obowiązkowej rejestracji w Systemie Uwierzytelniania Komisji Europejskiej
Serwery aplikacji. dr Radosław Matusik. radmat
www.math.uni.lodz.pl/ radmat Ciasteczka trwałe i sesyjne Ciasteczka trwałe - pozostają na komputerze użytkownika po zamknięciu strony, z której zostały pobrane / przeglądarki. Ciasteczka sesyjne - są związane
DOKUMENTACJA PROTOKOŁU SMESX. Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS Protokół w wersji 2.0
DOKUMENTACJA PROTOKOŁU SMESX Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS Protokół w wersji 2.0 Autor smeskom@smeskom.pl Data 2008-08-21 Wersja 2.0 (rev. 1) Spis treści Dokumentacja protokołu
Kontrola sesji w PHP HTTP jest protokołem bezstanowym (ang. stateless) nie utrzymuje stanu między dwoma transakcjami. Kontrola sesji służy do
Sesje i ciasteczka Kontrola sesji w PHP HTTP jest protokołem bezstanowym (ang. stateless) nie utrzymuje stanu między dwoma transakcjami. Kontrola sesji służy do śledzenia użytkownika podczas jednej sesji
Protokół HTTP 1.1 *) Wprowadzenie. Jarek Durak. rfc2616 źródło www.w3.org 1999
Protokół HTTP 1.1 *) Wprowadzenie Jarek Durak * rfc2616 źródło www.w3.org 1999 HTTP Hypertext Transfer Protocol Protokół transmisji hipertekstu został zaprojektowany do komunikacji serwera WW z klientem
Terytorialna analiza danych
Terytorialna analiza danych Dokumentacja systemu Marek Roj, Warszawa, luty 2013 Aktualizowano: 15.02.2013, wersja 0.196 Spis treści Wprowadzenie...3 Cel tego dokumentu...3 Informacje ogólne...3 Dokumentacja
XML-RPC: Zdalne wykonywanie procedur
XML-RPC: Zdalne wykonywanie procedur Bartłomiej Świercz Katedra Mikroelektroniki i Technik Informatycznych Łódź, 28 października 2005 roku Wstęp Internet dostarcza wiele możliwości programistą piszącym
Dokumentacja REST API v 3.0
Dokumentacja REST API v 3.0 Kraków, 26 kwietnia 2012 FreshMail, ul. Fabryczna 20a, 31-553 Kraków tel. +48 12 617 61 40, info@freshmail.pl, freshmail.pl Spis treści Opis API... 3 Uwierzytelnienie... 3 Odpowiedzi
pawel.rajba@gmail.com, http://itcourses.eu/ Adresy zasobów Rodzaje zawartości Negocjacja treści Komunikacja Buforowanie HTTP Request/Response Nagłówki Bezstanowość Cookies Narzędzia URL, http://www.ietf.org/rfc/rfc3986.txt
Sprawdzenie stanu opłacenia pakietu Zlecenie sprawdzenia stanu opłacenia... 23
I N T E R F E J S W E BSERVICES NADAWANIE PAKIETÓW D O S Y S T EMU MKP PRZEZ I N TERNET D O K U M E N T A C J A T E C H N I C Z N A G R U D Z I E Ń 2 0 1 8 Spis treści 1. Wstęp... 2 2. Informacje ogólne...
Wybrane działy Informatyki Stosowanej
Wybrane działy Informatyki Stosowanej JSP - Java Server Pages dr hab. inż. Andrzej Czerepicki a.czerepicki@wt.pw.edu.pl http://www2.wt.pw.edu.pl/~a.czerepicki 2019 Aplikacje i skrypty WWW klasyfikacja
Wszystkie dane powinny być przekazane za pomocą metody POST, zakodowane za pomocą funkcji urlencode().
Kraków 7 maja 2010 Dodawa nowego a Wszystkie dane powinny być przekazane za pomocą metody POST, zakodowane za pomocą funkcji https://app.freshmail.pl/main.php?modulename=fm_api&action=add_subscriber 1
Funkcje dodatkowe. Wersja 1.2.1
Funkcje dodatkowe SPIS TREŚCI 1.Wprowadzenie 1.1 Adresy URL do połączenia z aplikacją dla funkcji zarządzania kontem 1.2 Adresy URL do połączenia z aplikacją dla funkcji zarządzania polami nadawcy I. ZARZĄDZANIE
Technologie sieciowe Sprawozdanie z labolatorium. Lista 5
Politechnika Wrocławska Wydział Podstawowych Problemów Techniki Technologie sieciowe Sprawozdanie z labolatorium Lista 5 Autor: Piotr Kosytorz IIrokInf. indeks: 166174 Prowadzący: dr inż. Łukasz Krzywiecki
Ataki na aplikacje WWW. Łomem, czy wytrychem? Jak dobrać się do aplikacji WWW
Ataki na aplikacje WWW Łomem, czy wytrychem? Jak dobrać się do aplikacji WWW Ataki na aplikację Ataki na przeglądarkę Ataki na serwer WWW/kontener, etc. Często kombinacja i wiele etapów Którędy do środka
Języki programowania wysokiego poziomu. PHP cz.3. Formularze
Języki programowania wysokiego poziomu PHP cz.3. Formularze Formularze Sposób przesyłania danych formularza do serwera zależy od wybranej metody HTTP: Metoda GET
Proces obsługi deklaracji Intrastat w systemie Celina WebCel
Proces obsługi deklaracji Intrastat w systemie Celina WebCel Jednym ze sposobów przesłania deklaracji INTRASTAT do Polskiej Administracji Celnej jest skorzystanie z serwisu Celina Webcel, który służy przekazywaniu
Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP
Załącznik Nr 3 KDPW_CCP Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Wersja 1.0 Warszawa, czerwiec 2012 Spis treści Wstęp... 3 Budowa komunikatów XML... 3 Przestrzenie
System Przydzielenia i Pobierania Numerów Recept. Opis interfejsu dostępowego v. 1.0
System Przydzielenia i Pobierania Numerów Recept Opis interfejsu dostępowego v. 1.0 1 Wprowadzone zmiany Wersja Opis 1.0 Wersja bazowa 2 Wprowadzenie Przedstawiony dokument opisuje interfejs dostępowy
DOKUMENTACJA PROTOKOŁU SMESX. Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS. Autor smeskom@smeskom.pl Data 2007-11-04 Wersja 1.
DOKUMENTACJA PROTOKOŁU SMESX Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS Autor smeskom@smeskom.pl Data 2007-11-04 Wersja 1.0 Spis treści Dokumentacja protokoł u SmesX...2 1 Zawarto ść
Dokumentacja. Wersja: 1.5 Ostatnio zmodyfikowano: Strona 1
Dokumentacja Interfejs komunikacyjny opartego o technologię RESTful Web Services dla systemu ITS we Wrocławiu pozwalającego na zasilanie Repozytorium Danych ITS informacjami pochodzącymi z pojazdów Transportu
Spis treści DOKUMENTACJA TECHNICZNA. STS API wersja 1.1
Spis treści 1. Korzystanie z interfejsu STS API...2 1.1 Warunki korzystania z interfejsu...2 1.2 Zabezpieczenia interfejsu...2 2. Specyfikacja interfejsu STS API...3 2.1 Proces składania zamówienia za
RPC Remote Procedural Call. Materiały do prezentacji można znaleźć na stronie: http://www.houp.info/rpc
RPC Remote Procedural Call Materiały do prezentacji można znaleźć na stronie: http://www.houp.info/rpc 1 Wprowadzenie Podstawowe założenia RPC: Program uruchamiany na maszynie A może wywołać procedurę
QualitySpy moduł reports
QualitySpy moduł reports Testy akceptacyjne dla przypadku użycia: Pobranie metryk produktu w wybranym formacie dla wybranch wersji przez interfejs REST Nazwa pliku: /QualitySpy/modules/qualityspyreports/src/test/java/pl/wroc/pwr/qualityspy/reports
Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP
Warszawa, lipiec 2012 Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Wersja 1.1 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw
Internetowe bazy danych
Wyższa Szkoła Technologii Teleinformatycznych w Świdnicy Internetowe bazy danych wykład 6 dr inż. Jacek Mazurkiewicz e-mail: Jacek.Mazurkiewicz@pwr.wroc.pl Kontrola dostępu
Serwer SSH. Wprowadzenie do serwera SSH Instalacja i konfiguracja Zarządzanie kluczami
Serwer SSH Serwer SSH Wprowadzenie do serwera SSH Instalacja i konfiguracja Zarządzanie kluczami Serwer SSH - Wprowadzenie do serwera SSH Praca na odległość potrzeby w zakresie bezpieczeństwa Identyfikacja
Instrukcja logowania do systemu Rejestru Unii dla nowych użytkowników
Instrukcja logowania do systemu Rejestru Unii dla nowych użytkowników Przed pierwszym logowaniem do Rejestru Unii należy dokonać obowiązkowej rejestracji w Systemie Uwierzytelniania Komisji Europejskiej
Dokumentacja API. SOAP - webservice v. 0.2.1
Dokumentacja API SOAP - webservice v. 0.2.1 Zawsze wymagane parametry WSDL https://api.fabrykasms.pl/0.2/soap?wsdl http://fabrykasms.pl/api/acc/ przy koncie api wybieramy zdalne używanie aby uzyskać wszystkie
Konspekt pracy inżynierskiej
Konspekt pracy inżynierskiej Wydział Elektryczny Informatyka, Semestr VI Promotor: dr inż. Tomasz Bilski 1. Proponowany tytuł pracy inżynierskiej: Komunikator Gandu na platformę mobilną Android. 2. Cel
System obsługi zleceń na zaopatrzenie w wyroby medyczne. Opis interfejsu dostępowego v. 1.0
System obsługi zleceń na zaopatrzenie w wyroby medyczne interfejsu dostępowego v. 1.0 Katowice 2018 Wprowadzone zmiany Wersja 1.0 Wersja bazowa 2 Spis treści Wprowadzenie...4 ogólnego mechanizmu obsługi
Karol Gałka. Numer albumu: Inżynieria mechatroniczna
Karol Gałka Numer albumu: 285781 Inżynieria mechatroniczna rok III, grupa 1.2 Techniki informacyjne w praktyce inżynierskiej Sprawozdanie 4 Zad.1 HTTP - protokół przesyłania dokumentów hipertekstowych.
System ewuś. Opis interfejsu dostępowego v. 1.5
System ewuś Opis interfejsu dostępowego v. 1.5 Warszawa 2013 Wprowadzone zmiany Wersja Opis 1.0 Wersja bazowa 1.1 Dodanie opisu mechanizmu logowania 1.2 Aktualizacja związana ze zmiana formatu odpowiedzi
Protokoły zdalnego logowania Telnet i SSH
Protokoły zdalnego logowania Telnet i SSH Krzysztof Maćkowiak Wprowadzenie Wykorzystując Internet mamy możliwość uzyskania dostępu do komputera w odległej sieci z wykorzystaniem swojego komputera, który
Przelewy24. Specyfikacja techniczna instalacji. Przelewy24 Specyfikacja techniczna instalacji. Data: 2014-06-03 Wersja: 3.2
Przelewy24 Specyfikacja techniczna instalacji Data: 2014-06-03 Wersja: 3.2 Dokument zawiera specyfikację techniczną instalacji systemu płatności Przelewy24. Strona 1 z 15 Indeks Indeks... 2 1 Przebieg
Realizacja Aplikacji Internetowych 2013 laboratorium cz. 2 K.M. Ocetkiewicz
Realizacja Aplikacji Internetowych 2013 laboratorium cz. 2 K.M. Ocetkiewicz Walidacja po stronie klienta: - w MVC 3 i 4 domyślnie jest włączona także walidacja po stronie klienta - wykorzystuje ona JavaScript
ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja
ZPKSoft WDoradca 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja 1. Wstęp ZPKSoft WDoradca jest technologią dostępu przeglądarkowego do zasobów systemu ZPKSoft Doradca.