Lepší pochopení relací 4D REST

V předchozím příspěvku na blogu jsme vám ukázali, jak začít pracovat se serverem 4D REST. Provedli jsme vás různými CRUD operacemi pomocí Postmanu a odkázali vás na úplnou dokumentaci REST. V tomto příspěvku na blogu vám vysvětlíme, jak relace ve 4D fungují. Toto pochopení vám zajistí, že budete schopni vytvořit systém ověřování založený na relacích pomocí serveru 4D REST.

Relace 4D rest

Pokud máte zájem o vybudování autentizačního systému, systém založený na relacích je to, co hledáte!

Připojení k serveru 4D REST jsou založena na relacích. To znamená, že server 4D vytvoří relaci při odeslání prvního požadavku klientem a odešle mu zpět cookie relace (WASID4D). Při všech následujících požadavcích musí klient tento soubor cookie relace vrátit v hlavičce požadavku. To je v rozporu s ověřováním založeným na tokenech, kdy se na straně serveru žádná relace neuchovává, ale je uložena na straně klienta.

Konfigurace serveru REST

Nyní, když jsme dobře porozuměli tomu, jak se pracuje se sezeními, pokračujme dále. Než budeme moci začít, je třeba spustit a nakonfigurovat server 4D REST. Než budete pokračovat, podívejte se na tento příspěvek na blogu nebo do centra dokumentace.

O způsobu ověřování REST

The On REST Authentication Databázová metoda vám poskytuje vlastní způsob řízení způsobu otevírání relací REST ve 4D. Při přijetí požadavku na otevření relace REST jsou v hlavičce požadavku uvedeny identifikátory připojení(např. uživatelské jméno a heslo). Zavolá se metoda databáze On REST Authentication, aby bylo možné tyto identifikátory vyhodnotit a vrátit hodnotu True (otevření relace přijato) nebo False (otevření relace zamítnuto).

Poznámka: Ačkoli tato metoda slouží ke kódování vlastního řízení přístupu k databázi, přístup lze omezit také pomocí skupiny uživatelů 4D. Při vystavení databáze vyberte skupinu s povoleným přístupem na kartě Nastavení databáze > Web > Prostředek REST. Pro osvěžení paměti se podívejte na tento příspěvek na blogu.

Otevření relace

Pro ilustraci otevření relace si představíme odesílací formulář s přihlašovacím jménem a heslem. K odeslání přihlašovacích údajů v hlavičce požadavku POST použijeme Postman. Chcete-li otevřít relaci v aplikaci 4D prostřednictvím REST, použijte $directory/login:

Vraťme se zpět do 4D a podívejme se, co se děje.

Jak vidíte, metoda databáze přijímá čtyři parametry:

• $1 pro uživatelské jméno,
• $2 pro heslo,
• $3 vrátí True, pokud je heslo zaheslované, a False, pokud není,
• $4 obsahuje IP adresu volajícího.

Poznámka: V reálném světě by hesla měla být zaheslovaná a neměla by se posílat v otevřeném tvaru. Pro odeslání zaheslovaného hesla můžete místo parametru password-4D použít parametr hashed-password-4D . Podívejte se na tento příklad kódu, který ukazuje, jak postupovat.

Po přijetí požadavku server otevře relaci a odešle zpět klientovi soubor cookie relace (WASID4D):

Nyní, když byla naše relace vytvořena, jak můžeme předat její ID zpět v následných požadavcích HTTP?

Počkat … proč to vůbec musíme dělat?

Správa relací

HTTP je „bezstavový“ protokol … pokaždé, když se klient připojí k webové stránce, otevře samostatné spojení s webovým serverem. Server si neuchovává záznamy o předchozích požadavcích klienta. Představte si, že se k serveru připojují tisíce klientů, jak by server poznal, která relace je ta vaše? Právě zde přichází na řadu ID relace. Prostřednictvím této výměny ID relací se udržuje stav. Co to přesně znamená? No, znamená to, že abyste mohli znovu použít stejnou relaci, musíte zajistit, aby všechny následující požadavky REST obsahovaly ID relace v hlavičce požadavku„Cookie“. Jinak bude otevřena nová relace (a nová relace znamená novou licenci).

Příklad:

Způsob zpracování relací ve skutečnosti závisí na vašem klientovi HTTP. Řekněme, že se nacházíme v kontextu, kde jsou požadavky zpracovávány prostřednictvím příkazu HTTP Request.

Abychom mohli ID relace zahrnout do hlavičky, musíme ji nejprve najít. Snadno! Víme, že relace má klíč WASID4D, takže stačí tento klíč vyhledat v hodnotách hlavičky pomocí příkazu Find in array:

Find in array($headerValues; "WASID4D@")

Po nalezení jej extrahujeme:

$start:=Position("WASID4D";$cookie)
$end :=Position(";";$cookie)
$uuid := Substring($cookie;$start;$end-$start)Na adrese $uuid bude umístěno ID relace, které bude zasíláno ve všech následujících požadavcích. Kompletní příklad najdete zde.

Řízení časového limitu relace

Ve výchozím nastavení je časový limit nečinnosti relace 60 min a nesmí být kratší. Délku timeoutu však můžete zvýšit pomocí hodnoty parametru„session-4D-length„, který lze předat v hlavičkách POST pomocí metody $directory/login.

Ještě jedna věc

Server 4D má relaci ukládající výběry entit na základě předchozích dotazů nebo příkazů k objednávce. Proto když je potřeba další „rozsah“ (nebo kus) dat, nemusí se znovu dotazovat/objednávat, ale stačí poslat další sadu dat. Tento mechanismus umožňuje používat transakce, pesimistické zamykání a další.

Co bude dál?

Server REST byl ve verzi 4D v18 výrazně vylepšen a v budoucnu se chystají další funkce. Mezitím vám budeme nadále poskytovat příklady a praktické případy použití. Neváhejte se zapojit do diskuse na fóru 4D.