Poczta przychodząca z outlook.office365.com

W celu pobrania maili z serwera outlook.office365.com, należy skonfigurować pobieranie poczty przy pomocy protokołu EWS i logowania OAuth. Po wybraniu protokołu EWS (Ustawienia systemowe/Poczta przychodząca/Poczta przychodząca) i wskazaniu serwera outlook.office365.com, w ustawieniach procesu (w którym ma być obsługa poczty przychodzącej) pod polem [E-mail hasło] pojawi się link [Generuj token OAuth].

Aby wygenerować token OAuth do Office365, należy wpisać login konta, z którego chcemy pobierać maile, i nacisnąć [Generuj token OAuth]. W nowej zakładce pojawi się okienko do logowania na serwerze Microsoft.

Jeżeli będzie to pierwsze logowanie do OAuth, to pojawi się monit o potwierdzenie żądania uprawnień. Domyślnie AMODIT łączy się jako aplikacja AMODIT zweryfikowana na naszym koncie (patrz: dodatkowe uwagi na dole artykułu). Na poniższym obrazku jest niezweryfikowana aplikacja AMODIT2, ponieważ dla AMODIT było to już potwierdzone.

Po akceptacji pole z hasłem zostanie wypełnione tokenem OAuth. Nowe ustawienia należy zapisać.

Domyślnie AMODIT łączy się z Azure na wbudowanym koncie z domeny astrafox.pl. Klient może udzielić uprawnienia do logowania się w jego imieniu dla naszego konta (potrzebne są uprawnienia administratora w Azure AD).

Jeżeli klient nie chce dawać zgody na korzystanie z rejestracji w naszej domenie w Azure, to może wpisać w ustawieniach systemowych dane aplikacji ze swojej domeny. Aplikację należy zarejestrować na stronie: https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps
Instrukcja tworzenia aplikacji opisana jest na stronie: Konfiguracja aplikacji Azure na potrzebny logowania OAuth
Następnie w Ustawieniach systemowych w parametrze AzureApplicationConfig w sekcji Poczta przychodząca/Ustawienia EWS wpisać JSON w postaci:

Pobierz przykładowy plik JSON: AzureApplicationConfig-json.pdf

gdzie:

• client_id to identyfikator aplikacji (klienta) z parametrów aplikacji Azure;
  
• client_secret to wpis tajny wygenerowany dla aplikacji;
  
• w redirect_uris jest wpisany adres strony na którą nastąpi przekierowanie po uwierzytelnieniu w Azure. Ta strona musi być ustawiona jako strona przekierowania w Azure. W miejsce ???? w podanym adresie należy wstawić adres serwera AMODIT;
  
• AMODIT wymaga uprawnień do scope: offline_access https://outlook.office.com/EWS.AccessAsUser.All (dla poczty przychodzącej).

Dodatkowe uwagi:

• Aby zadziałało wypełnienie tokenem pola „E-mail hasło”, AMODIT musi być otworzony z tego samego adresu serwera, jaki jest wypełniony w polu redirect_uris (czyli dla przykładu http://localhost:54354 ). Inaczej wypełnienie pola „E-mail hasło” zostanie zablokowane z uwagi na próbę modyfikacji strony AMODIT z innej domeny.
• Powyższa funkcjonalności w systemie AMODIT jest dostępna od wersji 220325.
• Dla poczty wychodzącej wymagane scope to: offline_access https://outlook.office.com/mail.send
• Jeżeli po zalogowaniu w Microsoft i przekierowaniu do AMODIT dostajemy błąd 404 (dokładniej 404.15), to oznacza, że została przekroczona maksymalna długość query string w adresie. Domyślnie jest to 2048 znaków, a token z Microsoft może być dłuższy. Aby zwiększyć ten limit, należy dodać parametr maxQueryString w web.config AMODIT (przykład w web.config.txt):

  <security>
  <requestFiltering>
  <requestLimits maxAllowedContentLength="52428800" maxQueryString="4096" />
  </requestFiltering>
  </security>

• Dodatkowo należy dodać parametry maxQueryStringLength i maxUrlLength w tagu httpRuntime:

  <httpRuntime ... maxQueryStringLength="32768" maxUrlLength="65536"/>

• Jeśli klient chce korzystać z naszej aplikacji w Azure do uwierzytelnienia, a taka jest skonfigurowana domyślnie w AMODIT, to w pliku web.config musi się znajdować wpis:

  <add key="OAuthUrl" value="https://oauth.amodit.com" />

  I nic więcej nie trzeba robić.

• Jeśli klient chce korzystać z własnej aplikacji w Azure do uwierzytelnienia, to żadnego(!!!) wpisu dla parametru „OAuthUrl” nie może być w pliku web.config. Natomiast klient musi skonfigurować aplikację w Azure zgodnie z instrukcją przedstawioną w tym artykule powyżej. I teraz jeszcze jedna ważna rzecz, system AMODIT najlepiej gdyby działał po protokole HTTPS. Nawet jeśli jest on w sieci wewnętrznej. Na pewno musi on działać po protokole HTTPS na czas konfigurowania aplikacji w Azure. Istotne również jest to, aby podczas konfiguracji aplikacji w Azure jako identyfikator URI przekierowania podać dokładny adres systemu AMODIT w sieci wewnętrznej (najlepiej po HTTPS). No i oczywiście, aby to wszystko działało, to AMODIT musi „widzieć” świat zewnętrzny.