Here is a great Youtube Video by okta. The guy giving the talk made the tool called oauthdebugger.com and oidcdebugger.com – sweet. He humbly states – don’t do this or that even if you trust me. It helps us to be on the straight an narrow especially with (likely) someone else’s data and tools (our clients)

• Authorization code – the main one on the 1st part of the video
• Implicit (front channel) for things where the is no backend available
• Resource owner/pw – not used much but machine to machine backend
• Client Credentials – used to make old apps work but not used for new apps

OpenID Connect IS OAuth with an added scope called openid

I was quite miffed that Malwarebytes identified my code as a virus. I had some Excel VBA macros that downloaded files from sharepoint in a fractoin of the time compared to opening them as a file from SharePoint. Brilliant … until “MalwareBytes just saved your life by killing Excel for you before you were doomed forever” … but … but hey – my program just poof … gone. Changes, long macro (that during VPN/Covid days) takes forever and now … gone. After some debugging it was the line URLDownloadToFile that paused Excel for about 4 minutes before then caused MalwareBytes to kill it. I did put in a ticket (and expect it to never be addressed) but suggested that if a file is in the trusted sites list – perhaps don’t view that as an exploit. It is likely faster to re-program things.

Suggestions online only have 3 options to download from SharePoint.

• map a drive, use the drive (and optionally kill the drive mapping). This seems lame. Plus you are opening a file using Explorer type access – which I said was slow
• Use URLDownloadToFile() which – EVERYONE IS USING – that is why it is likely why people who make viruses use it – it seems to be quite popular with Virus developers
• REST – way to complicated – no one has done it without asking for usernames and passwords everytime (I did figure it out – and this is how I am doing it now)

Alas – I DID figure out the bits and pieces to NOT as for credentials and to camp-out on an existing connection to SharePoint. I am doing this from an Excel VBA macro – so we are 99% guaranteed that we are connected. Complicated – you have no idea – YES IT IS.

Here is my journey:

It sure takes many moons to see your drives if you switch to and from a VPN. We developed a switching app that maps drives to sharepoint or the VPN. After some digging around – i found a powershell script that did a System.IO.DriveInfo() command which seemed to delay things for a small amount but the drives became active right away. Cool I said. So i then modified it to do a

• netuse then
• System.IO.DriveInfo() then do a
  • and print out the status of each drive
  • and finally
• netuse (to see any changes)

It seems to work. The “ah ha” moment came from when I tried this program from this guy. I have since morphed it into function that accepts the drive letter and the \\server\share path and does a netuse in front and in back.

What a dizzying nightmare. First, web browsers NOW have a built in PDF capabilities so most people don’t have to install a 3rd party PDF viewer like Adobe or Nitro. I install these 3rd party PDF viewers on PC’s Mac OS X – but for heaven’s sake – don’t allow it to be the default on a Mac. Just don’t.

But for PC’s if you use Bluebeam for PC’s as your PDF viewer and the source of those PDFs is SharePoint – there are >5 layers of setting to consider and each browser has its quirks. Want to skip to the recommendation (which is just “live with it and learn how”? click here)