Best way to download data from Sharepoint (I'm in need for some automation) - json

Basically there are some shared Excel files on my corporation's Sharepoint and I need local copies of It for data analysis. I am able to manually download all I need, but I need to automate this work somehow.
I'm writing this post because of issues regarding two aspects of this problem:
Microsoft Licenses: as I'm using a personal account on a corporation domain (for my work), so Microsoft won't let me setup gateways on Power Automate. I was able to create a Power Automate Flow that does exactly what I need, but my end point is messed up (can't connect to my local machine so I can create the file I need with the data from Sharepoint). I cannot acess these files with other account.
Two-factor authentication: I'm unable to use APIs with Sharepoint apparently because of this, and the authentication is something that I cannot disable due to my corporation's policies.
Any workaround is viable? I need some new ideas.

You could use PnP.PowerShell to automate this task.
For authentication issue just register an app on the target site collection and grant is access. Then use this app credentials to connect to the SharePoint site and download the files.
Reference -
To create a new app - https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins/register-sharepoint-add-ins#to-register-by-using-appregnewaspx
Grant access to this app - https://learn.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azureacs#setting-up-an-app-only-principal-with-tenant-permissions
Use this app to authenticate - https://pnp.github.io/powershell/cmdlets/Connect-PnPOnline.html#example-3

Related

Where to store database credentials in Electron app

I just started on a new Electron project that needs to access a database, e.g. SQLite. The database will be on a shared drive that should be accessed by the Electron app.
To do that, I need to provide the path as well as the password for the database to the Electron app. Since it's desktop application, I deliver the whole application incl. the database credentials to the user.
From my point of view, this is not a good approach from a security perpective.
So the question is, where do I store these details, especially the credentials?
The same issue applies if I use e.g. another database like MySQL. There, I also need to store the host and the credentials.

Write to MS Access DB located on shared drive from Web Form

I am pretty sure the answer is "No" but I figured I would ask because I was not able to find a solid answer.
I am trying to create a web form that would write to an MS Access database that is stored on a Shared Network Drive. Is this something that is possible without a server?
No. Web forms require a web server to run (specifically, SharePoint server).
Interfacing with Access on a shared network drive is possible (either directly through Access or through another application), but not through a web form.
You can use an ODBC DNS to access a MS Access file that is share on a drive.

Share an access Database on Sharepoint

I have created quite a large Access 2016 db. It is now ready to share with the business and needs to be put onto SharePoint. I've tried just uploading the file to a SharePoint document library, however users cannot edit the database (there is a lot of VBA code that runs SQL commands that write data input by users into the database).
Is there a way to share the database that allows users to open it from SharePoint and let the VBA write to the database/tables?
That is not possible as SharePoint isn't an SMB fileshare, neither is OneDrive, DropBox, etc.
The SMB fileshare is offered by a Windows Server or a Linux box with Samba installed.

Is there a way to use an MS Access DB (MDB files) on Azure Websites?

We normally use Microsoft.ACE.OLEDB.12.0 to read and write from MS Access Databases. On a normal Server you can just install office or the AccessDatabaseEngine_x64.exe and this works fine.
Now we want to move our app to Azure (Preferably the Azure Websites and not WebRole or full VM). But there we obviously can't install the Access Drivers.
Is there another way to use Access on Azure? Maybe a 3rd party driver or something that can be run/installed with user privileges.
We looked at dotConnect, but as far as I understand, this still needs OLE DB.
Switching to Azure SQL is not an option, as Access is used as a "FileType" for a 3rd Party system that we use.
Specifically for a cloud service, you can do the following:
Create a cloud service that wraps your core project/site.
Include the MDB in the project that is wrapped from (1). Many ways to do that.
Include any executables or scripts you want to be deployed as well. You can add them to a Visual Studio project and set their Build Action to Content.
In the project that is wrapped, include a WebRole.cs file and implement RoleEntryPoint and specifically implement public override bool OnStart(). This will allow you to run scripts, move files on the file system etc.
The nice thing about using WebRole.cs to run your initialization code is that when Azure reimages your cloud service, the code will always run and get the machine back to a known state.

MS Access security (frontend vs. backend)

If I have an MS Access frontend that connects to an MS Access backend, is there a way to hide/permission block the pathway to the backend's folder such that they cannot access the backend database without severing the frontend/backend connection?
Right now I can't dedicate a server to a more "secure" form of DB or anything like that so I'm stuck with MS Access for now. I just don't want someone looking at, say, a link table path and then navigating to that folder and getting access to backend information. What might be some solutions to this?
With MS Access 2003 you can get some protection from user-level security Be very careful, the forums are full of people who have permanently lost access to their files. You should also create your own menus and compile. It is possible to disable the shiftkey open and all built-in menus, once again, this can lock you out of your file.
I know you have mentioned it, but I highly recommend that you migrate the backend to SQLExpress. The security model is much better and safer to use. SQL Express does not require a dedicated server and performs well on the desktop.
I think you can password protect your backend file.