Plik esystem.smd

Pliki wzorcowe

• Wzorcowy plik smd serwera

• Wzorcowy plik smd monitora

• Wzorcowy plik app

!!! Warning Uwaga! Plik *.smd jest wymagany do poprawnego działania Neosa jako runtime oraz serwis. Jeżeli plik konfiguracyjny nie zostanie wykryty, serwer zostanie automatycznie wyłączony a w logach pojawi się wpis Main definition file could not be found in path [ścieżka do pliku *.smd]

Parametry komunikacyjne

Przyznajemy unikalny port 9xxx, czyli w sekcji [AppService] ustawiamy port na którym ma działać serwer. Opcjonalnie możemy także przyznać port do usługi serwera poprzez protokół HTTP i OData (obowiązkowo o 1 i 2 większy numer portu). Protokół HTTP jest potrzebny do pracy klienta WEB Neosa oraz do mechanizmu transferu plików pomiędzy klientem VCL a serwerem Neos. Przy korzystaniu z klienta WEB należy ustawić port dla protokołu OData, który odpowiada za przesyłanie danych. Port Odata musi być zawsze o 1 większy od portu HTTP. Jeśli uruchamiasz serwer ze źródeł pod Visual Studio, protokół HTTP zadziała tylko wtedy, gdy Visual Studio zostało uruchomione z prawami administratora.

[AppService]
ServerServiceAdress=localhost:9000
HttpServerServiceAdress=localhost:9001
ODataServiceAdress=localhost:9002
WebsocketServerServiceAdress=localhost:9003 

Od wersji 4.6 nastęujące wpisy przeszły do sekcji HTTPServer już bez literówek
[HTTPServer]
HttpServerServiceAddress=localhost:9011
ODataServiceAddress=localhost:9012
WebsocketServerServiceAddress=localhost:9013

Uwaga

Od wersji 4.0.17 doszedł nowy serwis WebsocketServerServiceAdress, który służy do zaimplementowania funkcji RefreshClient dla WEB (odświeżenie listy komunkatów z serwera na żądanie). Jeżeli nie używacie klienta WEB nie trzeba go podawać. Jeżeli natomiast używacie zwróćcie uwagę (najlepiej dragonom), aby port na którym stoi był otwarty dla ruchu TCP/IP nie HTTP.

Uwaga

Od wersji 4.3.4 została wydzielona sekcja [HTTPServer], do której zostały przeniesione parametry konfiguracyjne związane z serwerem HTTP, tj:

• HttpServerServiceAddress
• WebsocketServerServiceAddress
• MaxThreadsForHttpServer
• PlainHttpServer
• EnableHttpCaching
• EnableHttpLongAuth
• HttpLongAuthTimeout
• WWWLoginTry
• WWWBlockLoginInterval
• WWWEnableHttps
• ClientWWWDevMode

Ponadto została poprawiona literówka w parametrach [HttpServerServiceAddress] i [WebsocketServerServiceAddress]. Zmianie uległo [...Adress] na [...Address].

Logowanie kontem GOOGLE

Do aplikacji WEB możemy zalogować się używając konta google. Włączenie logowania kontem google następuje po odpowiednim zautoryzowaniu serwera NEOS w GOOGLE oraz dodaniu poniższej konfiguracji do pliku SMD. Jak autoryzować serwer NEOS w google znajdziesz tutaj: Logowanie kontem google do aplikacji WEB

[HTTPServer]
LoginByGoogleEnabled=yes
LoginByGoogleAppId=#klucz uzyskamy w procesie autoryzacji serwera w GOOGLE#

Nowy edytor kodu C#

W neosie i S4 od wersji 4.6 został osadzony nowy edytor kodu. Na razie domyślnie włączony jest stary cseditor. Aby zadziałał nowy konieczne jest dokonanie w smd następującego wpisu:

[AppService]
CodeEditorServiceAddress=localhost:9004

Neos musi być uruchomiony z prawami administratora.

Tryb developera

W neosie od wersji 4.7 został wprowadzony nowy parametr konfiguracyjny o nazwie DeveloperMode. Ustaw ten parametr na 1 jeśli na środowisku developerskim często rozwijasz aplikację w NEOSie. Po ustawieniu parametru na 1 NEOS przy starcie będzie cache'ował odpowiednie biblioteki aby szybciej uruchamiać edytor kodu C#. Wiąże się to ze wzrostem użycia pamięci RAM, dlatego nie jest zalecane uruchamianie tego na środowisku produkcyjnym.

[Configuration]
DeveloperMode=1

Automatyczne wylogowywanie martwych sesji

Po ustawieniu parametru RemoveDeadSessionsAfter (w Neosie 4.3.5.4; dawniej InactivityPeriod). Parametr podawany jest w minutach (domyślna wartość to 60). Serwer Neosa będzie przeglądał zalogowane sesje użytkowników i usuwał te, które nie wysłały komunikatu, że żyją przez okres równy podwojonej wartości RemoveDeadSessionsAfter. Dzięki czemu oszczędzane są zasoby serwera w momencie gdy użytkownik nie wyloguje się jawnie, tylko zamknie kartę przeglądarki lub zabije proces SenteS4.exe.

[AppService]
#w minutach, domyślnie gdy nie ustawione, to jest 60 minut
RemoveDeadSessionsAfter=60

Po ustawieniu parametru RemoveInactiveSessionsAfter (w Neosie 4.3.5.4). Parametr podawany jest w minutach (domyślna wartość to 1440 czyli 1 dzień). Serwer Neosa będzie przeglądał zalogowane sesje użytkowników WEB i usuwał te, które nie przejawiały żadnej aktywności (czyli nie wywoływały funkcji na serwerze).

[HTTPServer]
#w minutach, domyślnie gdy nie ustawione, to jest 1440 minut
RemoveInactiveSessionsAfter=60

Istnieją dwa parametry dodatkowe w AppService:

• SessionsPingInterval, który steruje tym, jak często klient ma informować serwer, że żyje - domyślnie jest to nie rzadziej niż raz na godzinę, nie częściej niż raz na minutę, 4 razy częściej niż wartość RemoveDeadSessionsAfter
• SessionsSweepInterval, który steruje tym, jak często będziemy przeglądać sesje kliencie w poszukiwaniu martwych i nieaktywnych sesji. Algorytm wyznaczania domyślnej wartości jest dość skomplikowany, dzieje się to nie rzadziej niż raz na 15 minut i nie częściej niż 1 na minutę, kilka razy częściej niż wynosi mniejsza z wartości RemoveDeadSessionsAfter i RemoveInactiveSessionsAfter

Przykłady

Przykład

Chcę aby użytkownik zalogowany do WEB do Nowego Taskmana, którego zakładka działa, mógł na niej pracować bez wylogowywania przez co najmniej dwa tygodnie Ustawiamy tylko

[HTTPServer]
#20160 = 60 * 24 * 14
RemoveInactiveSessionsAfter=20160

Dodatkowo przy takich ustawieniach, jeżeli użytkownik jednak zamknie zakładkę, sesja zostanie usunięta po 2 godzinach z serwera. Jeżeli chcielibyśmy aby następowało to po np. 10 minutach, dopisujemy

[AppService]
RemoveDeadSessionsAfter=5

Przykład

Chcę aby użytkownik zalogowany do WEB do profilu ING, mógł na niej pracować, tak długo jak wykonuje operacje, ale po ich zaprzestaniu chcę go wylogować po godzinie +/- dwie minuty Ustawiamy

[HTTPServer]
RemoveInactiveSessionsAfter=60
[AppService]
SessionsSweepInterval=2

Ponownie zamknięte zakładki spowodują usunięcie sesji na serwerze po 2 godzinach, jeżeli chcemy aby miało to miejsce po 10 minutach

[HTTPServer]
RemoveInactiveSessionsAfter=60
[AppService]
RemoveDeadSessionsAfter=5

Przykład

WebAPI

Zalogowana sesja WebAPI powinna zostać wylogowana przez klienta WebAPI. Jeśli to nie nastąpi należy skonfigurować odpowiednią nastawę

[HTTPServer]
RemoveInactiveWebApiSessionsAfter=5

Nastawa ta mówi o długości istneinia sesji WebAPI. Domyślnie parametr ten wynosi: 3 minuty, ale należy doliczyć jeszcze 2 minuty na czas aż Sweeper oznaczy połączenie do wyrzucenia (1min) oraz, czas posprzątania w kolejnym przebiegu sweepera (1min), czyli sumarycznie od zalogowania sesja zostanie zutylizowana po 5 minutach.

Ścieżki do projektów

Należy skonfigurować w sekcji [BusinessPlatform] ścieżki do projektów w taki sposób aby wskazywały na katalog Neos.Projects z repozytorium neos a po średniku na katalog o tej samej nazwie z pobranego repozytorium eSystem.win, np.:

ProjectPath=..\..\Neos.Projects;S:\Neos.Projects
DllPath=libraries
CustomProjectPath=customprojects

Jeżeli chcemy uruchomić klienta WEB należy w sekcji [BusinessPlatform] ustawić domyślny projekt. np.:

DefaultProject=SENTE

Możliwe jest ładowanie przez serwer projektów z kliku branchy, które będą używane alternatywnie. Jest to szczególnie przydatne w procesie emisji, gdy serwer porównuje definicję projektów z dwóch branchy i umożliwia przenoszenie zmian z jednego na drugi. Aby załadować dodatkowe źródła z brancha o symbolu release, piszemy np tak:

ProjectPath:release=D:\release\Neos.Projects
DefaultProject:release=SENTE

Po dwukropku występuje dowolny alias brancha. Można w ten sposób załadować dowolną ilość branchy.

Jeżeli chcesz korzystać z mechanizmu BinaryFile w Neosie w połączeniu z kontrolką WebBrowser, a pliki udostępniać przez wbudowany serwer http, podaj następujący parametr:

BinaryFileDir=\\apoc\DRO\work\files

Wpisz w nim ścieżkę, pod jaką serwer Neosa będzie widział katalog BinaryFile

Wczytywanie bpacków

Serwer neos wczytuje pliki bpack z folderów wskazanych w parametrach BinariesPath, ProjectPath oraz z głównego folderu serwera. !!! Warning "Uwaga!" Skompilowane projekty nie będą się wczytywać z podfolderów głównego folderu (wyjątkiem są ścieżki wskazane w parametrach BinariesPath albo ProjectPath, które się znajdują wewnątrz głównego folderu)

Wsadowe budowanie bpacków

Jeśli chcesz aby serwer neos wsadowo wygenerował ze wskazanych projektów pliki bpack a następnie się zamknął, umieść dodatkowe linijki:

BinariesPath=bin
PackProjects=SENTE

gdzie zamiast SENTE możesz wpisać dowolną listę projektów oddzielonych średnikiem. W BinariesPath podajemy ścieżkę do katalogu w którym mają być zapisywane pliki bpack. Jeżeli nie dodamy wpisu BinariesPath to pliki zapiszą się w katalogu gdzie znajdują się wszystkie pliki (np. plik smd)

Oprócz tego od wersji 4.0.9 będziesz musiał podać trzy obowiązkowe parametry w wierszu poleceń:

• --build-repo
• --build-branch
• --build-author

Zostały one dodane po ty, aby móc śledzić losy danego bpacka i w razie czego szybko znaleźć źródła z których powstał, co znacznie przyspiesza debugowanie ewentualnych błędów.

start /w Neos.Runtime.exe ^ :: dzięki temu proces neosa uruchomi się, a skrypt zaczeka aż się skończy
 -s ..\..\addings\jenkins\buildsystem.smd ^ :: wskazanie .smd z PackProjects
 --build-repo Neos ^ :: nazwa repozytorium, z którego pochodzi wygenerowany bpack
 --build-branch 4.0.9 ^ :: nazwa brancha, z którego pochodzi wygenerowany bpack
 --build-author Jenkins ^ :: nazwa osoby/automatu który dany bpack wygenerował

Definicje baz danych

Firebird

Należy usunąć definicje wszystkich połączeń do baz danych za wyjątkiem bazy system, gdyż bazy danych rejestruje klient podczas logowania ze swojego pliku app. Dzięki temu każdy klient pod tym samym aliasem np esystem może wskazać inną bazę danych. Bazę danych w pliku smd rejestrujemy jedynie wtedy, gdy chcemy uruchomić moduły workflow lub scheduler, gdyż te moduły muszą mieć wskazaną bazę danych na której działają. Rejestrując bazę danych musimy pamiętać o tym, że connection string, czyli ścieżka do bazy nie może przekraczać 255 znaków, gdyż przy uruchomieniu klienta będzie to powodowało błąd Invalid connection string, a samej rejestracji bazy dokonujemy w następujący sposób:

    [Configuration]
    Databases=system;esystem
    DefaultDatabase=esystem   <- aby domyślną bazą (np dla reguł odpalanych z schedulera) była baza esystem

    [Database:system]
    DatabaseDriver=MEM

    [Database:esystem]
    DatabaseFile=10.168.1.170:/mnt/db/esystem.fdb <- connection string do bazy danych
    DatabaseDriver=FB
    EnablePartialFill=yes
    MaxConnections=100
    DatabaseConfFile=esystem.dbi
    DatabaseRole= #rola na jaką chcemy się zalogować do bazy. Jeżeli nie podamy to logujemy się bez roli
    User=     #jeżeli komunikat o braku 
    Password= #hasła do bazy esystem
    AutoCommitTimer=60 #w sekundach
    DatabaseCharset=WIN1250     #może też być UTF8
    ConnectionPoolerPolicy=PreferNew //Strategia puli połączeń, gdzie preferowane są nowe. Brak tej nastawy lub innej jej wartość powoduje strategię Standard czyli używania wolnych połączeń
    ConnectionPoolerPolicyCloseNotUsedAfter=120 // Czas po jakim nieużywane połączenia będą zamykane. Domyślnie jest to 10 minut.

    //Od wersji NEOS'a 6.0 
    //Wpisy ConnectionPoolerPolicy, ConnectionPoolerPolicyCloseNotUsedAfter, AutoCommitTimer, EnablePartialFill nie są obsługiwane
    EnablePooling=yes <- włączenie puli połączeń (domyślnie włączone)
    MaxConnectionLifetime=15 <- czas życia połączenia przy bezczynności w sekundach

Uwaga!

Koniecznie wszystkie aliasy baz danych należy wymienić w kluczu Databases sekcji Configuration oddzielając je średnikiem.

Uwaga!

Jeżeli nie chcesz podawać plain textem hasła do bazy danych to możesz skorzystać z mechanizmu przekazywania ustawień poprzez parametry

Microsoft SQL Server - baza na fizycznym serwerze bazodanowym

W przypadku konfiguracji połączenia do bazy danych dla serwera Microsoft SQL Server, możemy to zrobić na dwa sposoby: tak jak poniżej, lub tak jak w przykładzie podanym dla bazy wystawionej przez usługę Microsoft Azure. Przykład poniższy pozwala na swobodne wskazanie adresu IP i portu. Ten sposób jest zalecany, gdy serwer bazodanowy hostuję bazę na niestandardowym porcie i nie mamy po stronie serwera, żadnego mechanizmu, który przekieruje nas na odpowiedni port, gdy podamy alias tego serwera. Jeżeli po stronie serwera administrator wystawi taką usługę, to wtedy możemy użyć sposobu z wykorzystaniem parametru DatabaseFile. W tym przypadku serwer Neos rozbija podaną ścieżkę zgodnie z następującym wzorcem DatabaseFile=alias_serwera:katalog inicjalizacji bazy(nazwa bazy danych)

[Database:symfoniatest]
DatabaseHost=192.168.0.139,50521 #Adres i port na którym został wystawiony serwer bazodanowy
DatabasePath=WMS #Nazwa pod jaką utworzyliśmy bazę na serwerze bazodanowym
DatabaseDriver=MSSQL
EnablePartialFill=yes
MaxConnections=20
DatabaseConfFile=esystem.dbi
User=nazwa_uzytkownika
Password=haslo_uzytkownika

Microsoft SQL Server na Azure

Przykład rejestracji bazy chmurowej

[Database:Subiekt]
DatabaseFile=azmdvm01.database.windows.net:AZBD01
DatabaseDriver=MSSQL
EnablePartialFill=yes
MaxConnections=20
DatabaseConfFile=esystem.dbi
User=nazwa_uzytkownika
Password=haslo_uzytkownika

Weryfikacja ustawień domyślnej BD. NEOS vs S4

Od wersji 4.6 został wprowadzony mechanizm sprawdzania poprawności konfiguracji domyślnych BD w serwerze NEOS jak i kliencie S4. Jak wiadomo domyślna baza danych do której łączy się S4 oraz NEOS musi być identyczna choćby ze względu na przeprowadzanie autentykacji użytkownika. Mechanizm weryfikuje czy ścieżka do BD skonfigurowana w NEOSie (smd) jest identyczna jak ścieżka do BD w aplikacji S4 (app). Gdy ścieżki się różnią zostaje wyświetlone ostrzeżenie w balloonhint z odpowiednią informacją. Jeśli z jakiś powodów jesteśmy pewni, że BD są identyczne ale ścieżka do BD są inne możemy ten mechanizm dezaktywować za pomocą poniższej konfiguracji. Domyślnie weryfikacja jest włączona.

[Configuration]
CheckDatabaseOnStartup=0

Automatyczny restart połączeń do baz danych

Od wersji 4.0.6 można włączyć restart połączeń codziennie o godzinie 23.

[Configuration]
AutoReconnectDBEnabled=yes

Czas kiedy ma następować restart można swobodnie zmieniać używając parametru AutoReconnectDBCronExpression. Parametr ten jest w formacie NCrontab. Jeśli nie znasz tego formatu, użyj kreatora.

[Configuration]
#domyślnie codziennie o 23
AutoReconnectDBCronExpression=0 23 * * *
#co godzinę, miedzy 7 a 17 od poniedziałku do piątku
AutoReconnectDBCronExpression=0 7-17 * * MON,TUE,WED,THU,FRI

Workflow (stary - usunięty)

Jeśli posiadamy w pliku sekcję [Workflow] z poniższymi wpisami, to usuńmy te wpisy, bo stary workflow i tak nie działa, bo został usunięty.

StartWorkflowService=yes - używajmy tylko 'no' lub usuńmy wpis
WorkflowDatabase=esystem
WorkflowDefaultProject=SENTE
SettingParametersProcedure=WORKFLOW_SET_GLOBAL_PROCEDURE - opis w 'Ustawienie parametrów globalnych dla automatów'

Scheduler

Jeśli chcemy aby działał moduł schedulera to w sekcji [Scheduler] wpisujemy dodatkowo:

StartSchedulerService=yes //parametr opcjonalny, jeśli go nie ma to scheduler jest włączony
Interval=1   // co ile minut odpala się scheduler
SchedulerDatabase=esystem
SchedulerDir=libraries <- katalog na skompilowane reguły
DaysAfterRemoveHistory - opisany na stronie schedulera
AutoRemoveHistoryCronExpression - opisany na stronie schedulera
SettingParametersProcedure=SCHEDULER_SET_GLOBAL_PROCEDURE - opis w 'Ustawienie parametrów globalnych dla automatów'

gdzie zamiast esystem wpisujemy alias bazy danych ze strukturami schedulera.

Strażnik Schedulera

Począwszy od wersji 4.2.11 istnieje możliwość skonfigurowania strażnika, który będzie pilnował czy scheduler działa i reguły się wykonują i w przypadku błędu wyśle egołębia^[1] na wskazany adres(-y). W sekcji [Scheduler] wpisujemy dodatkowo:

GuardEnabled=yes //czy włączyć strażnika
GuardInterval=1  //co ile minut strażnik będzie się budził ze snu i robił obchód czy wszystko gra
GuardTimeout=10  //ile czasu musi minąć od ostatniego wykonania kodu schedulera który uruchamia metody, aby podnieść alarm
GuardLastInstanceEnabled=yes //czy strażnik ma kontrolować także czas wykonania pojedynczych reguł
GuardLastInstanceTimeout=120 //po ilu minutach, dzwonić na alarm, jeżeli reguła ciągle trwa - wartość MAKSYMALNA dla wszystkich reguł

Należy też skonfigurować wpisy w sekcji dotyczącej wysyłania maili oraz komu wysyłać wiadomości

Uwaga!

Aby nie generować niechcianego spamu strażnik działa tak, że jeżeli wyśle egołębia^[2] to wydłuża odpowiedni timeout (GuardTimeout albo GuardLastInstanceTimeout) dwukrotnie, aż do wartości jednego dnia (24*60 minut). Łatwo sprawdzić, że to znaczy, iż nawet jak ustawicie timeout na 1 to wyśle Wam nie więcej niż 10 egołębii zanim zacznie je rozsyłać raz dziennie. W momencie gdy strażnik stwierdzi, że brak jest błędów wyśle jeszcze jednego egołębia^[3] z informacją, że problemy ustąpiły i wróci do rutynowych timeoutów, tak jak to jest ustawione w pliku smd.

Scheduler w trybie jednej reguły

Istnieje możliwość skonfigurowania specjalnej wersji serwera neos, która uruchomi jedynie pierwszą do wykonania regułę schedulera, wykona ją, a następnie się zakończy. Taki serwer można periodycznie uruchamiać np. z schedulera windowsowego. W tym celu konfigurujemy specjalny plik smd, w którym sekcję [Scheduler] konfigurujemy następująco:

StartSchedulerService=onerule //tryb pojedynczej reguły
SchedulerDatabase=esystem
SchedulerDir=libraries <- katalog na skompilowane reguły

W takim pliku najlepiej w sekcji [Plugins] w ogóle usunąć plugin bp,aby ładowanie projektów neosowych nie zabierało niepotrzebnie czasu imocy procesora. Na takim neosie i tak nie można uruchamiać aplikacjiokienkowych.

Scheduler wsadowy odpalamy poprzez:

Neos.Runtime.exe -s smdschedulera.smd

Proces serwera pracuje tak długo, jak długo trwa pojedyncza reguła, którą uruchomi.

Imap

Ta sekcja zawiera ustawienia automatycznego procesu synchronizacji poczty w tle

[IMAP]
StartSynchroService=yes   <- uruchamia automat sprawdzający automatycznie nowe wiadomości
Interval=5   <- co ile minut sprawdzane są nowe wiadomości
EmailMetadataDatabaseAlias=esystem
EmailContentDatabaseAlias=xxxxxxx
SettingParametersProcedure=IMAP_SET_GLOBAL_PROCEDURE - opis w 'Ustawienie parametrów globalnych dla automatów'

Można tu włączyć automat sprawdzający w tle czy istnieją nowe wiadomości dla wszystkich skrzynek IMAPowych. Jeśli dana skrzynka ma włączony tryb pełnej synchronizacji, to wiadomości są od razu pobierane. W przeciwnym razie widać w drzewie folderów, ile jest nowych wiadomości ale ich pobieranie odbywa się dopiero po kliknięciu w dany folder. W ramach folderów także można określić, które podlegają automatycznej synchronizacji, a które nie.

Jeżeli treści maili są przechowywane w tej samej bazie to parametry EmailMetadataDatabaseAlias i EmailContentDatabaseAlias powinny wskazywać na ten sam alias bazy danych (np. esystem). Dla konfiguracji z dwiema bazami należy dodać alias drugiej bazy danych w pliku .smd (np. emailwiad), podać parametry połączenia a w szczególności określić czy połączenie do drugiej bazy ma być w utf: DatabaseCharset=UTF8. Następnie należy alias drugiej bazy dodać także do pliku .app.

Obsługa certyfikatów

Czasem w rzadkich przypadkach zdarza się, że serwer poczty ma komunikację zabezpieczoną nieprawidłowym certyfikatem. Przykładowo pewien wesoły admin ustawił na serwerze poczty na domenie xyz.com certyfikat na *.zyx.com. Co zrobić, gdy chcemy mieć komunikację bezpieczną, zmiana certyfikatu na prawidłowy potrwa kilka miesięcy? Neos od wersji 4.6.33, wprowadza następujące ustawienia:

• Żeby przetestować, czy to rzeczywiście tylko wina certyfikatu dodaj do sekcji [IMAP]

IgnoreCertificateValidation=yes

• Bardziej poprawnie - zajrzyj do logów Neosa, przy łączeniu z serwerem IMAPa zobaczysz wpisy "Certificate details:" i klucze "Name", "Issuer" itp. Po potwierdzeniu, że certyfikat został wystawiony przez zaufaną stronę

CertificateValidationWhitelist=SN:xxxyyyyy&TH:zzzzzxxxxx;

Gdzie SN to jest serial number, a TH to thumbrint. Można podać listę kluczy, w takim wypadku wpisy należy rozdzielić średnikiem.

konfiguracja klienta WEB

Konfiguracja produkcyjna/deweloperska

Serwer Neosa odsyła dwie wersje klienta WEB - deweloperską, której pod żadnym pozorem nie powinno się upubliczniać w otwartej sieci WEB, oraz produkcyjną. Przełączanie dokonuje się za pomocą ustawienia zmiennej ClientWWWDevMode.

[HTTPServer]
ClientWWWDevMode=yes

Jeżeli takiego wpisu nie ma lub też jest ustawiony na no, klient będzie próbował wczytać pliki .min.js (które są dostępne w wersjach emitowanych przez nas, a które można również wygenerować samodzielnie ze źrodeł). Jeżeli natomiast ustawimy tam yes klient będzie wczytywał pliki źródłowe, co ułatwia rozwijanie i znajdowanie błędów.

Https

Aby włączyć obsługę protokołu https dla klienta WEB należy ustawić parametr

[HTTPServer]
WWWEnableHttps=yes

Oprócz tego wymagana jest pewna ilość operacji administracyjnych, zarejestrowanie certyfikatu w systemie, umożliwienie aplikacji korzystania z portu po protokole https. Dla systemu Windows skrótową instrukcję można znaleźć tutaj

Ustawienia sesji użytkownika

Neos >= 4.7

Od tego neosa unowocześniona została infrastruktura zarządzania sesją. Do zalogowanego klienta przesyłane są dwa klucze, jeden dostępowy klient załącza do każdej operacji. Klucze mają swoje daty ważności, po upływie których korzystanie z danej instancji klienta nie jest możliwe (trzeba się przelogować). Klient wie kiedy mu się klucz skończy i używa drugiego klucza do wygenerowania nowego klucza dostępowego. Zupełnie osobną ale powiązaną sprawą jest mechanizm, który dba o to, aby usuwać sesje użytkowników na serwerze jeżeli nie generują oni żadnej aktywności. O osiągnięciu pewnego czasu bezczynności sesja klienta jest usuwana z serwera. Jeżeli użytkownik jednak spróbuje potem zrobić coś na stronie albo ponownie na nią wejść, to jeżeli ma ważne klucze, serwer utworzy mu nową sesję bez konieczności ponownego logowania. Podobnie jeżeli serwer zostanie zrestartowany, klienci stracą swoje sesje, ale z ważnymi kluczami wejdą do aplikacji bez logowania.

Konfiguracja łatwa prosta i przyjemna

Za sterowanie tym odpowiada parametr

[AppService]
SimpleSessionSettings=mode:[M];valid:[V];inactive:[I]
#przykłady użycia
#SimpleSessionSettings=mode:business;valid:7d;inactive:24h
#SimpleSessionSettings=mode:strict;valid:10m;inactive:5m

Mechanizm może działać w dwóch trybach [M]:

• business - tryb biznesowy. Używaj gdy chcesz osiągnąć podobny efekt jak przy logowaniu przez google, aby po zalogowaniu użytkownik długo nie musiał się ponownie logować. Parametrem [V] sterujesz jak długo użytkownik nie musi martwić się logowaniem. Jeżeli będzie aktywnie korzystał z aplikacji pod koniec okresu, to ten czas może ulec wydłużeniu. Parametrem [I] dajesz neosowi szansę na zwolnienie zasobów i zamknięcie okien, jeżeli użytkownik nie korzysta aktywnie z aplikacji po upływie określonego czasu.
• strict - tryb bezpieczny. Używaj gdy chcesz osiągnąć podobny efekt jak przy logowaniu na konto bankowe, aby po zalogowaniu użytkownik nie korzystający aktywnie z aplikacji został wylogowany. Parametrem [V] sterujesz jak długo może trwać sesja użytkownika. Jeżeli będzie aktywnie korzystał z aplikacji pod koniec okresu, to ten czas może ulec wydłużeniu. Parametrem [I] mówisz po jakim czasie od ostatniej aktywności użytkownik zostanie wylogowany.

Parametry [I] oraz [V] przyjmują liczbę minut, możesz użyć przyrostków d dla dni, h dla godzin i m dla minut (domyślnie).

Ważne!

Ustawienie tego parametru wpływa na ustawienie innych parametrów (patrz sekcja zaawansowane), m. in. na zarządzanie w Neosie sesjami w ogóle. Część tych ustawień będzie dotyczyć także sesji VCL.

Ważne!

Aktualnie wydane klucze są przechowywane w pliku customprojects\.webtokens. Są zaszyfrowane i nie będą działać jeżeli przeniesie się Neosa do innej lokalizacji lub podepnie inny plik głównej bazy danych. Raz wydane klucze obowiązują przez cały czas do wyznaczonej daty ich wygaśnięcia i przeżywają restart serwera. To znaczy, że jeżeli użytkownik najpierw dostał klucz ważny przez tydzień, a potem zmieniliśmy ustawienia na przykład na 1 dzień, to wszystkie nowe klucze będą wydawane na ten okres. Aby unieważnić klucze wydane wcześniej i zmusić użytkowników do przelogowania po prostu skasuj plik .webtokens gdy serwer nie jest uruchomiony.

Konfiguracja zaawansowana

To są parametry

[AppService]
AccessTokenDuration=
RefreshTokenDuration=
RemoveInactiveSessionsAfter=
LogoutTokenPolicy=strict

[HTTPServer]
SessionsSweepInterval=
RemoveDeadSessionsAfter=
SessionsPingInterval=

Neos < 4.7

Na starszych neosach jeżeli chcemy uzyskać efekt, że użytkownik loguje się do WEB raz i przez wiele dni nie musi się ponownie logować, trzeba korzystać z logowania przez konto google, jako że opisane poniżej rozwiązanie działa w kratkę.

Token przedłużonego pamiętania użytkownika

O ile automatyczne wylogowywanie służy oszczędzaniu zasobów serwera, o tyle dzięki temu mechanizmowi, nawet gdy sesja zostanie usunięta użytkownik ma szansę jeszcze przez pewien czas zalogować się do aplikacji bez podawania hasła. Co więcej jeżeli wejdzie do aplikacji ponownie, serwer automatycznie go zaloguje do nowej sesji. Mechanizm zapamiętuje z jakiego ip i z jakiej przeglądarki nastąpiło logowanie i zadziała tylko, gdy dane będą zgodne. [AppService]

#Czy mechanizm jest włączony
EnableHttpLongAuth=yes
#Okres ważności tokena. Przyrostek h oraz brak przyrostek oznacza godziny, przyrostek m oznacza minuty.
HttpLongAuthTimeout=8h

Stopka

1. W pliku smd w sekcji AppService wpisy FooterCssPath i FooterHtmlPath określają style do formatowania stopki i stronę z kodem html do jej wyświetlenia. Np:

FooterCssPath=footer/footer.css
FooterHtmlPath=footer\footer.html

Uwaga!

Dla parametru FooterHtmlPath Neos na początku dokleja folder Files, w związku z tym dla powyższego przykładu plik fizycznie znajduje się w następującej ścieżce <lokalizacja plików serwera Neos>\Files\footer\footer.html

Customowe logo Web

W folderze <NEOS>\Files\Icon znajdują się pliki wykorzystywane w logo strony. Aby dodać własnego logo należy skopiować do tego folderu swoje customowe pliki.
Zakładamy, że format nazwy pliku logo jest następujący: <CommonLogoPrefix>-logo[-white][_mobile].png, np.: sente-logo-white_mobile.png Ponad to muszą istnieć 4 pliki dla każdego logo:

• standardowe (<CommonPrefix>-logo.png)
• standardowe do mobilnych (<CommonPrefix>-logo_mobile.png)
• dla ciemnego tła (<CommonPrefix>-logo-white.png)
• dla ciemnego tła do mobilnych (<CommonPrefix>-logo-white_mobile.png)

Następnie w pliku SMD dodajemy:

[WWWCustomization]
CommonLogoPrefix=nasz_prefix

Customowe elementy strony logowania Web

Żeby zmienić zaznaczone elementy strony logowania

należy przeciążyć klucze w następującej sekcji:

[TeneumCustomization]
CompanyName=<nazwa_firmy>
CompanyLogoPath=<ścieżka_do_logo_png>
CompanyDisplayLink=<napis_linku>
CompanyLink=<adres_linku>

Profile

W pliku smd można skonfigurować profile dla klienta WEB. W tym celu należy dodać sekcje [Profile:<nazwa profilu>]. Na przykład:

[Profile:klient]
Name=Panel klienta
LoginProcedure=SYS_GET_USERINFO_UZYKLI
ChangePasswordProcedure=SYS_CHANGE_PASSWORD_UZYKLI
Modules=EHRM;EPER 
DefaultProject=SENTE 
DefaultDatabase=esystem
StartObject=SENTE.MOJEDANE 
StartMethod=ShowPanel 
CustomCss=Files\styles\custom.css
UsesDepartments=yes
ResetTokenExpireTime=1440
ModulesInNavigator= 
ProjectsInNavigator=

Dodatkowo w sekcji [BusinessPlatform] możemy ustawić domyślny profil dodając wpis: DefaultProfile=<nazwa profilu>.

Od wersji 5.4 wprowadzono mechanizm resetu hasła za pomocą @. Po wygenerowaniu linku z tokenem resetującym hasło token ten ma określoną ważność. Domyślnie 24h jednak można to skonfigurować per profil kluczem: ResetTokenExpireTime który przyjmuje ilość minut przez które token będzie aktywny.

Od wersji 5.4.9 do ustawień profili został dodany mechanizm zarządzania nawigatorem(wstążką).
Klucz ModulesInNavigator określa jakie moduły będą załadowane do wstążki. Żeby dany moduł został załadowany klucz ProjectsInNavigator musi być pusty, lub zawierać projekt, zawierający moduły, do których chcemy się ograniczyć. Pojawienie się znacznika „none", powoduje nie załadowanie się żadnego modułu Możliwe wartości: <modul>;<modul>|none np. ModulesInNavigator=WFL;DOK lub ModulesInNavigator=none

Listę dostępnych modułów neosowych można zobaczyć w oknie zarządzania rolami i uprawnieniami. Wystarczy włączyć filtr na moduły.

Klucz ProjectsInNavigator określa jakie projekty zostaną załadowane do akcji na wstążce. Jeśli klucz jest pusty ładujemy wszystkie projekty Neosowe. Jeśli ma wartość none - nie ładujemy żadnych projektów. Dodatkowo znacznik ModulesInNavigator ogranicza ładowanie do konkretnych modułów z danego projektu. Jeśli ograniczamy ładowanie do modułów, zostaną również załadowane nieprzypisane do żadnego z modułów akcje w obrębie zdefiniowanych do załadowania projektów Możliwe wartości: <projekt>;<projekt>|none np. ProjectsInNavigator=SYSTEM:WORKFLOW lub ProjectsInNavigator=none

Customowy plik css dla profilu

[Profile:klient]
CustomCss=Files\styles\custom.css

Można podać tylko jeden taki plik w ścieżce do której dostęp ma serwer http (w przybliżeniu Files i podfoldery).

Wielojęzyczność dla profilu

Od wersji neosa 5.3.10, wprowadzono możliwość konfiguracji wielojęzyczności w sekcji profilu. Dodano w tym celu trzy klucze:

[Profile:klient]
DefaultLanguage=en
Name:en=client
Languages=pl;en;de

DefaultLanguage działa tak, jak klucz DefaultLanguage w BusinessPlatform, a więc ustala domyślny język klienta oraz nadpisuje globalny klucz (z bp), gdy korzystamy z tego profilu.

Klucz "Name:xx", gdzie dwa znaki po ":" to skrótowa nazwa języka, odpowiada za tłumaczenie nazwy profilu, którą widzimy w menu klienta web oraz na ekranie logowania. Ten klucz działa tak, jakbyśmy zdefiniowali nazwę profilu w panelu tłumaczeń i, gdy mamy klienta web po angielsku, to wyświetla nam angielską nazwę, a gdy po polsku, to polską. (funkcjonalność dostępna od 5.3.9)

Languages określa listę języków dozwolonych dla danego profilu. Gdy przechodzimy do ekranu logowania, dostajemy możliwość wyboru języka spośród wszystkich z tej listy. Klucz uzupełniamy skrótami, a więc, aby w dropdownie mieć pełne nazwy tych języków, potrzebujemy w bazie tabeli Languages z odpowiednimi wpisami. Z racji, że ekran logowania też jest wielojęzyczny, to każda nazwa jest dodatkowo przepuszczana przez mechanizm tłumaczeń kontekstowych, aby wyświetlić nam odpowiednią nazwę.

Tytuł zakładki strony

Od wersji 5.4.6 lub 5.3.16 istnieje możliwość ustalenia tytułu zakładki klienta web teneum. Domyślnie wyświetlane jest "Teneum"

Można to zrobić per profil, w sekcji profilu, jak również globalnie, w sekcji HTTPServer.

[HTTPServer]
TabTitle = Tytuł strony

lub

[Profile:nazwa]
TabTitle = Tytuł strony

Cacheowanie plików

Serwer Neosa od wersji 4.0.6.2 posiada możliwość przesyłania w odpowiedzi na zapytania przeglądarki o pliki samego klienta nagłówków Cache-control, dzięki czemu powtórne zapytania o te pliki są serwowane z lokalnego cache przeglądarki. Można to włączyć parametrem

[HTTPServer]
EnableHttpCaching=yes

Cacheowanie jest domyślnie ustawione na 7 dni,po tym czasie powinny się pobrać nowe wersje plików. Włączenie tej opcji może spowodować problemy jeżeli zmienimy coś w kodzie klienta, użytkownicy będą widzieli stare wersje, co momentu nie przeładowania strony ctrl-f5 lub nie wyczyszczenia cache w przeglądarce.

Globalna wyszukiwarka (global search)

Od wersji 4.7 można podaćb obiekt wraz z formą, który posłuży za globalną wyszukiwarkę w kliencie WEB. Aby tego dokonać należy skonfigurować w profilu następujące klucze:

[Profile:test]
GlobalSearchObjectName=MOJ_OBIEKT_DO_WYSZUKIWANIA
GlobalSearchFormName=BROWSE

Gdy nie ustawimy tych kluczy, to GQS stanie się niewidoczny. Widocznością GQS możemy sterować także z poziomu modułów w profilu, gdy mamy restrykcyjne menu, za GQS odpowiada moduł o tej samej nazwie. Więcej na temat globalnej wyszukiwarki można poczytać tutaj.

Blokowanie logowania

W kliencie WEB po 3 nie udanych próbach logowania możliwość ponownego logowania będzie dostępna dopiero za 5 minut. W sekcji '[AppService]' możemy skonfigurować ilość prób w parametrze 'WWWLoginTry' oraz czas jaki ma upłynąć do ponownego logowania w parametrze 'WWWBlockLoginInterval'. Interwał podajemy w minutach. Przykład poniżej.

[HTTPServer]
WWWLoginTry=5
WWWBlockLoginInterval=2 - w minutach

Rozszerzenia websocketów

Od wersji 4.6.30 można wyłączyć przesyłanie nagłówka Sec-WebSocket-Extensions, a tym samym obsługę rozszerzeń websocketów.
Jest to przydatne jeżeli pomiędzy serwerem Neos a klientem stoi proxy skonfigurowane na IIS. Mechanizm ARR (Advanced Request Routing) odpowiedzialny za kierowanie ruchem nie obsługuje kompresji ramek, ale puszcza nagłówek, więc po wysłaniu przez klienta powitania serwer nie zwraca żadnego potwierdzenia.

[AppService]
WebsocketExtensions=no (domyślnie "yes")

Nagłówek Content Security Policy oraz X-Frame-Options

Content Security Policy (CSP) to dodatkowa warstwa zabezpieczeń, która pomaga wykrywać i łagodzić niektóre typy ataków, w tym ataki typu Cross-Site Scripting (XSS) i wstrzykiwanie danych.

[HTTPServer]
ContentSecurityPolicy=yes (domyślnie "yes")

Inne opcje to "no", gdzie wyłączamy tą warstwę zabezpieczeń oraz "report", która nie blokuje nic jednak wysyła raporty do konsoli.

Nagłówek X-Frame-Options służy natomiast do wskazania czy przeglądarka powinna mieć możliwość renderowania strony w \<frame>, \<iframe>, \<embed> lub