Page 2 of 2 FirstFirst 1 2
Results 16 to 29 of 29

Thread: Office 365 koppeling

  1. #16
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Quote Originally Posted by Hans Brenkman View Post
    Hi,

    Zou je de instellingen voor de REST Debugger kunnen delen, behoudens uiteraard je specifieke inloggegevens?

    MS stopt met SMTP/IMAP zonder OAUTH2 per 01-10-2022. Dus ik moet er nu mee aan de slag maar met al die instellingen in Azure AD ... ik kom er nog niet aan uit om met alleen het accounttype "één tenant" een accestoken te verkrijgen. Wel met Indy met de instelling "meerdere tennants" maar ik begrijp dat OAUTH2 SMTP / IMAP m.b.v. Indy niet de juiste weg is maar met REST moet (via MS Graph).
    Ik heb het vorige week uitgeleverd voor GMail. Wij gebruiken nu EASendmail. Zij hebben een goede demo met gebruik van OAuth2. Ook voor MS.

    Overigens wil ik over op ip-works, vanwege native connection. Indy kan het ook, maar zie liever heil in een tool door door ontwikkeld wordt.
    Delphi is great. Lazarus is more powerfull

  2. #17
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,861
    Quote Originally Posted by GolezTrol View Post
    REST is een architectuur voor communicatie tussen twee systemen, dia meestal, maar niet per se over HTTP loopt, en vaak, maar niet noodzakelijk JSON gebruikt. Maar til er niet al te zwaar aan. Een gewone website voldoet al vrijwel aan de definitie voor REST, en heel veel REST services voldoen ook niet aan de volledige standaard. "Dataverkeer over HTTP tussen een client en een server" is wat de meeste mensen bedoelen met REST, en om mee te beginnen is dat voldoende om te weten.

    En dat kan prima met Delphi en Indy. Delphi heeft een TRESTClient, maar volgens mij gebruikt die intern ook Indy.

    OAuth2 is dan weer een specifieke stap om een bepaalde set berichten heen en weer te sturen, om zodoende een token te krijgen, waarmee je toegang krijgt tot de rest van de API. OAuth 2 is dus een authenticatie-flow (over HTTP). Zie het een beetje als de receptie in een hotel of bij een groot bedrijf. Je meldt je aan, laat je paspoort zien, en krijgt uiteindelijk een pasje waarmee je door kan lopen en sommige deuren kan openen en andere niet. De procedure bij de receptie is de OAuth handeling, de authorisatie. Het pasje is de token die je krijgt. De kamers/faciliteiten zijn de API's, die je dus wel of niet kan gebruiken met je token.
    Ik ben enigszins bekend met API's en heb inmiddels verschillende koppelingen gemaakt. Maar in die gevallen krijg ik een username, password en één URL van de leverancier en krijg ik op basis van de authenticatie methode BASIC een accestoken. De eerste uitdaging zit 'm nu vooral in het inrichten van Azure AD met het registreren van een applicatie om alle instellingen goed te hebben en een accestoken met de authenticatie methode OAUTH2 te kunnen verkrijgen. Met de RESTDebugger krijg ik wel een statuscode "200 OK" terug, te samen met veel data, maar geen accestoken om daarmee verder te kunnen gaan.
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  3. #18
    Heb je een access_token, gebruik die om te communiceren samen met client_id en client_secret.
    Heb je geen access_token dan
    ** heb je een refresh_token, gebruik die dan om een nieuwe access_token te krijgen
    ** heb je geen refresh_token dan
    **** heb je een authorize_token, gebruik die dan om een nieuwe refresh_token te krijgen
    **** heb je geen authorize_token, haal die dan op via de AuthorizationUrl (gebruikerstoestemming nodig met authorize scherm)

    Tot hoever kom je en bij welke URL krijg je 200 terug?
    (dus welke url met welke code gebruik je om een access_token te vragen?)

  4. #19
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,861
    De URL is "https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize" waarbij de {tenant-id} uiteraard het ID van onze organisatie is

    Click image for larger version. 

Name:	25-05-2022 12-23-37.jpg 
Views:	229 
Size:	79.5 KB 
ID:	8226

    In RESTDebugger button "Step #1: Autorize" met onderstaande url (alles achter elkaar)

    https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize
    ?client_id=769be70d.....
    &response_type=code
    &redirect_uri=https%3A%2F%2Flogin.microsoftonline. com%2F{tenant-id}%2Foauth2%2Fv2.0%2Fauthorize
    &scope=https%3A%2F%2Foutlook.office.com%2FIMAP.Acc essAsUser.All%20https%3A%2F%2Foutlook.office.com%2 FPOP.AccessAsUser.All%20https%3A%2F%2Foutlook.offi ce.com%2FSMTP.Send

    krijg ik dit terug:

    Click image for larger version. 

Name:	25-05-2022 12-30-42.jpg 
Views:	197 
Size:	15.7 KB 
ID:	8227

    Alsof ik geen "client_id" verstuurd zou hebben (?)

    Als ik zie wat er allemaal in Azure AD ingesteld kan/moet worden... (en dat is bij de Google API's al niet anders).
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  5. #20
    Klopt. Sommige API's zijn open en kan je gewoon aanroepen. Maar de meeste vereisen enige vorm van authenticatie. Basic authentication is inderdaad een username en password.
    Die stuur je mee in headers bij een request. Specifiek voor dit soort API's is het onwenselijk.

    Als je een applicatie maakt die gebruik maakt van een account van een ander (bijvoorbeeld een een handig tooltje dat het aantal ongelezen mails laat zien in de taakbalk), dan is het voor de gebruiker onveilig om zo'n applicatie z'n username en password te geven. Die applicatie kan die gegevens namelijk direct doorgeven aan de ontwikkelaar, of onveilig opslaan zodat een andere applicatie er ook bij kan.

    In plaats daarvan kan je een flow als deze gebruiken om zo'n token te krijgen. Dat is in feite niet heel anders dan een wachtwoord, maar het is specifiek voor deze situatie.

    Je applicatie stelt zicht voor en vraagt om toestemming.
    In een webpagina van de provider (Google, Outlook, Office365), wordt die toestemming gevraagd aan de eindgebruiker ("Applicatie X wil toegang tot... Mag dat?").
    De gebruiker logt in met z'n username en password (en eventuele aanvullende beveiliging)
    De applicatie krijgt een token, wat in feite ook een soort wachtwoord is, waarmee hij verder requests kan uitvoeren.

    Er zit dus weinig verschil tussen een token en een wachtwoord op zich, alleen de manier waarop je het krijgt is anders. En dat is voor de veiligheid van de eindgebruiker.

    Er zijn natuurlijk ook APIs die een op een voor een ander werken. Neem bijvoorbeeld een API van PostNL om labeltjes aan te melden. Er is dan vaak geen derde partij, of die partij heeft geen expliciet account waarmee hij zelf tokens kan regelen. Je mailt een account manager, krijgt een contract, en bij dat contract krijg je de credentials (password of token), om met hun API te praten. De (meestal visuele) stappen om dat token te krijgen sla je dan over. Iemand bij de provider van de API regelt dat voor je.
    1+1=b

  6. #21
    Quote Originally Posted by Hans Brenkman View Post
    Alsof ik geen "client_id" verstuurd zou hebben (?)
    Hmm Dat lijkt toch wel de manier te zijn. De melding zegt 'request body', dus ik dacht dat het misschien niet in de url query parameters mocht, maar zo lijken ze het in de documentatie ook te doen. Weet je zeker dat er niet toch een line break in de url staat? Per ongeluk gekopieerd uit het voorbeeld?
    Edit boxjes laten die vaak niet zien, ook al zijn ze er wel. Misschien even volledig samenstellen in Notepad en daarvandaan naar de rest debugger kopieren.
    1+1=b

  7. #22
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,861
    Quote Originally Posted by GolezTrol View Post
    Weet je zeker dat er niet toch een line break in de url staat?
    Voordat de URL verstuurd wordt, kopieer ik die naar het clipboard. Die plak ik handmatig in NotePad++ en dan is het één regel zonder LF. Als extra deze naar een bestand geschreven: ook één regel.
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  8. #23
    Quote Originally Posted by Hans Brenkman View Post
    Voordat de URL verstuurd wordt, kopieer ik die naar het clipboard. Die plak ik handmatig in NotePad++ en dan is het één regel zonder LF. Als extra deze naar een bestand geschreven: ook één regel.
    Hoe verstuur je die URL dan?
    Dit is een URL die je direct in de browser moet laden.
    Dus niet via een GET o.i.d. proberen binnen te halen.
    Want dit is een interactieve pagina waar de gebruiker toestemming moet geven.

    De Scope komt mij niet helemaal bekend voor.
    Ik gebruik
    openid email profile offline_access https://outlook.office.com/user.readbasic.all https://outlook.office.com/mail.read

    Maar ik gebruik ook common op de plaats van tenant want ik heb dit nog nooit hoeven te testen voor Office for Business.
    Maar hoe doe je dat als er een andere tenant wil mailen?

    O, en je redirect Uri vind ik ook raar.
    Die moet toch iets als localhost zijn? Om na de authenticatie de code direct terug te krijgen?
    Je krijgt die code n.l. terug via een redirect naar je eigen server.
    Ik heb dus een kleine TTCPBlockSocket op http://localhost:1500

    Mijn Url voor Authenticatie
    Code:
    https://login.microsoftonline.com/common/oauth2/v2.0/authorize
    ?response_type=code
    &client_id=xxxx
    &redirect_uri=http%3A%2F%2Flocalhost%3A1500
    &scope=openid%20email%20profile%20offline_access%20https%3A%2F%2Foutlook.office.com%2Fuser.readbasic.all%20https%3A%2F%2Foutlook.office.com%2Fmail.read
    Na authentication wordt de gebruiker doorgestuurd naar http://localhost:1500/?code=M.R3_BL2.f2a32b26-xxxx
    Ik kan in die kleine TTCPBlockSocket thread dan de URL uitlezen en M.R3_BL2.f2a32b26-xxxx gebruiken als Authorize_token.
    En als result op die localhost pagina geef ik dan een melding dat het programma toegang heeft gekregen en ze die pagina kunnen sluiten.

    Als je niet met een localhost wil werken dan zul je de pagina die de gebruiker na zijn authorization krijgt uit moeten lezen voor de code. En anders moet de gebruiker de code die hij te zien krijgt in het scherm handmatig in je programma intikken. Vandaar dat de localhost methode het makkelijkste is.
    Last edited by rvk; 25-May-22 at 18:09.

  9. #24
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,861
    Quote Originally Posted by rvk View Post
    Hoe verstuur je die URL dan?
    Dit is een URL die je direct in de browser moet laden.
    Dus niet via een GET o.i.d. proberen binnen te halen.
    Want dit is een interactieve pagina waar de gebruiker toestemming moet geven.
    Inderdaad met een GET
    Quote Originally Posted by rvk View Post
    De Scope komt mij niet helemaal bekend voor.
    Ik gebruik
    openid email profile offline_access https://outlook.office.com/user.readbasic.all https://outlook.office.com/mail.read

    Maar ik gebruik ook common op de plaats van tenant want ik heb dit nog nooit hoeven te testen voor Office for Business.
    Maar hoe doe je dat als er een andere tenant wil mailen?

    O, en je redirect Uri vind ik ook raar.
    Die moet toch iets als localhost zijn? Om na de authenticatie de code direct terug te krijgen?
    Je krijgt die code n.l. terug via een redirect naar je eigen server.
    Ik heb dus een kleine TTCPBlockSocket op http://localhost:1500
    Met http://localhost:2132 als redirect Uri én de door jou gebruikte scope kom ik iets verder:

    Click image for larger version. 

Name:	25-05-2022 20-47-04.jpg 
Views:	242 
Size:	40.1 KB 
ID:	8228

    Na "accepteren" de melding "deze site is niet bereikbaar. Localhost heeft de verbinding geweigerd." maar ik kom dus al iets verder (denk ik).

    Die scopes en localhost poort had ik uit een demo programma GMailAuthDemo (ook voor MS) https://github.com/geoffsmith82/GmailAuthSMTP.

    Als ik mijn applicatie in Azure AD registreer als multi-tenant dan kan ik wel authenticeren en een een accestoken verkrijgen en een mailbox lezen. De URL is dan idd "https://login.microsoftonline.com/common/oauth2/nativeclient", dus met "common". Echter, multi-tenant is voor meerdere organisaties met meerdere domeinen (heb ik me laten uitleggen door onze SaaS provider). Aangezien we maar 1 domeinnaam hebben en omdat MS het om diverse redenen adviseert, dien ik dus te kiezen voor één tenant. Eenmaal ingelogd in de mail van die tenant kun je natuurlijk naar elk mailadres mailen, ook buiten die tenant.

    Een deel van mijn applicaties zijn serviceapplicaties die om de zoveel tijd mail ophalen (Office365 IMAP4), dus daar komt geen user aan te pas om de toegang goed te keuren. Ander applicaties wel t.b.v. madExcept indien er foutmeldingen zijn. Dan dropt de applicatie simpelweg een bericht naar een SMTP-server op basis van ip-adres en poort (dit is géén Office365 mailserver) en de SMTP-server pakt dit op en stuurt het aan geadresseerden. Die niet-Office SMTP-server gaat er ook uit, dus madExcept zal straks ook via Office365 moeten mailen. madExcept voorziet op dit moment ook niet in OAUTH2 dus hoe dat moet gaan weet ik ook nog niet (en de producent van madExcept weet het ook nog niet, oppert een HTTP-upload).
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  10. #25
    Quote Originally Posted by Hans Brenkman View Post
    Met http://localhost:2132 als redirect Uri én de door jou gebruikte scope kom ik iets verder:
    ..
    Na "accepteren" de melding "deze site is niet bereikbaar. Localhost heeft de verbinding geweigerd." maar ik kom dus al iets verder (denk ik).
    Yep. En als je dan in de adresbalk van de browser kijkt op die pagina dan zie je: http://localhost:2132/?code=M.R3_BL2.f2a32b26-xxxx
    Dat is dus die code achter je localhost die je nodig hebt.
    Ik gebruik daar dus een hele kleine http server voor.
    Niets bijzonder. Gewoon een TTCPBlockSocket in thread die op inkomend verkeer let.
    En als die dan komt een pagina teruggeeft (klein beetje html) en de URL ontleedt en die authorization code pakt.

    Quote Originally Posted by Hans Brenkman View Post
    Als ik mijn applicatie in Azure AD registreer als multi-tenant dan kan ik wel authenticeren en een een accestoken verkrijgen en een mailbox lezen. De URL is dan idd "https://login.microsoftonline.com/common/oauth2/nativeclient", dus met "common". Echter, multi-tenant is voor meerdere organisaties met meerdere domeinen (heb ik me laten uitleggen door onze SaaS provider). Aangezien we maar 1 domeinnaam hebben en omdat MS het om diverse redenen adviseert, dien ik dus te kiezen voor één tenant. Eenmaal ingelogd in de mail van die tenant kun je natuurlijk naar elk mailadres mailen, ook buiten die tenant.
    Ok, bij mij weet ik natuurlijk niet welk domein mijn klanten hebben dus moet ik multi-tenant hebben. Maar als je dit maar voor 1 domein (je eigen domein) gebruikt dan hoeft dat dus niet.

    Quote Originally Posted by Hans Brenkman View Post
    Een deel van mijn applicaties zijn serviceapplicaties die om de zoveel tijd mail ophalen (Office365 IMAP4), dus daar komt geen user aan te pas om de toegang goed te keuren.
    Ja, dat wordt dan een heel ander probleem. Want voor OAuth2 is toch echt gebruikers-interactie nodig. Er zijn wel service authentaction mogelijkheden maar die heb ik nog nooit onderzocht.

    Quote Originally Posted by Hans Brenkman View Post
    Ander applicaties wel t.b.v. madExcept indien er foutmeldingen zijn.
    Ja, daar zou ik dus nooit e-mail voor gebruiken. Wat als een gebruiker gewoon Thunderbird heeft. Of Outlook met een pop3-boxje. Als je weet dat ie altijd Office365 heeft met een business account (zoals jij al omschreef) dan is het misschien geen probleem. Maar bij mij werkt dat dus niet.

    Vandaar dat ik voor mijn Exception-dialoog (gebaseerd op Jedi) inderdaad een upload doe naar mijn eigen server (een simpele PHP upload pagina). Vandaar stuur ik een mail naar mijzelf. Maar dan is het bij de klanten dus lekker stabiel (alleen POST via HTTPS) en heb daar geen behoefte aan allerlei SMTP of mail gedoe.

  11. #26
    Zo zou ik het inderdaad ook doen. Loggen over HTTPS en daarvandaan ergens wegschrijven en/of mailen. Nooit de email-instellingen van de klant gebruiken om logs naar je te mailen. Dat was al lastig toen bijna iedereen nog gewoon Outlook op Exchange had.
    1+1=b

  12. #27
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,861
    Quote Originally Posted by rvk View Post
    Ik gebruik daar dus een hele kleine http server voor.
    Niets bijzonder. Gewoon een TTCPBlockSocket in thread die op inkomend verkeer let.
    En als die dan komt een pagina teruggeeft (klein beetje html) en de URL ontleedt en die authorization code pakt.
    Hoe moet ik dat zien? http://localhost:2132 verwijst naar de pc/omgeving waarop de applicatie draait naar poort 2132. Vermoedelijk heb je dan in je applicatie een thread TTCPBlockSocket (Synapse?) die op inkomend verkeer let.

    BTW, de Outlook REST API via https://outlook.office.com/api gaat ook dit jaar uit de lucht dus ook de scope zal ook aangepast moeten worden:

    The Outlook REST APIs are deprecated.

    The Outlook REST endpoints will be fully decommissioned in November 2022. Migrate existing apps to use Microsoft Graph.
    https://docs.microsoft.com/en-us/out.../compare-graph
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  13. #28
    Quote Originally Posted by Hans Brenkman View Post
    Hoe moet ik dat zien? http://localhost:2132 verwijst naar de pc/omgeving waarop de applicatie draait naar poort 2132. Vermoedelijk heb je dan in je applicatie een thread TTCPBlockSocket (Synapse?) die op inkomend verkeer let.
    Yep, dat had ik in mijn beide posts ook al aangegeven
    Het is de makkelijkste en stabielste methode om die code te pakken te krijgen. Anders moet je een externe browser uit gaan lezen (welke is dan gebruikt?) of de gebruiker de code over laten tikken.

    Quote Originally Posted by Hans Brenkman View Post
    BTW, de Outlook REST API via https://outlook.office.com/api gaat ook dit jaar uit de lucht dus ook de scope zal ook aangepast moeten worden:
    https://docs.microsoft.com/en-us/out.../compare-graph
    Ja, dat zag ik.

    Op Azure zelf staat weer dit:
    We will not retire the Azure AD Graph API on June 30, 2022. Listening closely to your feedback about the challenges of migrating such a critical dependency, we’re delaying the retirement date through at least the end of this year. We’ll provide a retirement update mid-calendar year with information on additional tools to assist with your migration.
    Dus ik moet inderdaad voor het einde van het jaar eens kijken hoe die migratie moet. Probleem is alleen dat ik momenteel met een van mijn Microsofts account buitengesloten ben door de Authenticator loop hell (geen account in de authenticator maar hij vraagt er wel om als enige mogelijkheid). Hopelijk kunnen ze dat bij Microsoft snel oplossen.

  14. #29
    Senior Member ErikB's Avatar
    Join Date
    Aug 2010
    Location
    Biddinghuizen
    Posts
    509
    Quote Originally Posted by jkuiper View Post
    Ik heb het vorige week uitgeleverd voor GMail. Wij gebruiken nu EASendmail. Zij hebben een goede demo met gebruik van OAuth2. Ook voor MS.

    Overigens wil ik over op ip-works, vanwege native connection. Indy kan het ook, maar zie liever heil in een tool door door ontwikkeld wordt.
    Hi John, ik ben benieuwd of je die overstap inderdaad ook gemaakt hebt (van EASendmail naar IP-works). IP-Works is behoorlijk duurder, ik ben er nog niet helemaal achter wat de meerwaarde er nu van is t.o.v. EASendMail.
    Erik

Page 2 of 2 FirstFirst 1 2

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •