is there a way to create a access web app and use as database an azure sql database. and use it as the main application database or a secondary one.
Either is it possible to create a database that is shared over more than one sharepoint app.
Last but not least is there a way to catch the visitors microsoft mail and use it in a macro to change the views depending on the accesslevel we want him to have on our app.So we can create for example user based profile, either with that way or with creating a user login and registration form.
Thanks in advance.
is there a way to create a access web app and use as database an azure sql database
When you design and modify in Access 2013 or later, the data and database objects are stored in SQL Server or Microsoft Azure SQL Database, so you can share the data within your organization using on-premises SharePoint 2013 or Office 365 for business.
Last but not least is there a way to catch the visitors microsoft mail
You could use the Access Custom Web App Function to get the email address , it could be used in user interface (UI) macros .
UserEmailAddress Function (Access custom web app)
Related
I've developed a VSTO add-on for Outlook that my company uses which connects to a SQL database to read/write data. I'd like to change the data source to SharePoint Online since all employees have M365 accounts. This will also allow the add-on to operate outside of the corporate network.
If I setup a SharePoint online site with a few lists, is there a way to have the Outlook VSTO Add-on read/write from the lists?
Also, since the Outlook client is already authenticated, is there a way to bypass any sort of authentication and use the already authenticated Outlook client when talking to SharePoint?
No, you need to consider your add-in as a standalone .Net based application. You can use the SharePoint client object model (CSOM) to retrieve, update, and manage data in SharePoint. Read more about that in the Complete basic operations using SharePoint client library code article.
I have developed a logic app, which receives a post request with JSON Object and I create external user in azure active directory. Till here everything is fine. Now I want to grant permission to newly created user to access our sharepoint site. There is a solution using Plumsail action connector but I do not want to use it. I want to achieve this using microsoft graph api.
Can you help me to achieve this?
Best way I think is adding the user to a group (with the AD connector) or using dynamic group to pick up the user. Then you can have sharepoint license connected to the group and have sharepoint access on the group.
Is it possible to secure SharePoint rest APIs?
I have a SharePoint portal that allows users to create accounts an get access to the portal.
The portal uses SharePoint client object model, if any of the users try to access let's say getuserbyid method or retrieving items for lists and changes the ID value, he will be able to retrieve information for other users on the portal.
So it is possible or is their any way to restrict access to the rest APIs outside the portal itself? Because with manipulation using Fiddler or burp suite the request can be replayed with different information or values.
The operations performed by the Client Side Object Model respect the SharePoint site permissions in the SharePoint site you are interacting with. You need to set/customize the site permissions such that you get the results that you want.
As a follow-up question to REST API to manage users on skype for business, I would like to understand how the Sharepoint Server User API differs from MS Graph API for Users. The Graph documentation indicates that we could use it to manage Sharepoint users the same way we would Office 365 users. However, there are standalone Sharepoint installations (like versions e.g. 2007, 2010, etc.,) which don't fall under Office 365 plans.
The Graph API Docs linked above says the User resource represents an "Azure AD user account". However, the Sharepoint User doc says it represents a "user in Microsoft SharePoint Foundation." Are these users entirely different from each other?
All we're looking to do is manage users for our clients some of whom have subscriptions to Office 365 and some who just use standalone Sharepoint setup. We are not bothered about application specific features like Accessing the sharepoint files, sites or even managing Word documents, Excel sheets, etc., So, does the Graph API support managing users in such cases as well?
That API is only for SharePoint 2013+
The user management REST API linked in your question is specifically for SharePoint 2013, and presumably works in SharePoint 2016 as well. This is regardless of whether the SharePoint environment is on premises or in the cloud.
Office 365 is currently a subset of SharePoint 2013/2016 in terms features and functionality.
Note that SharePoint 2007 and 2010 will not have this API.
SharePoint users and Azure AD accounts are not synonymous
Consider that SharePoint and AD can exist independently of each other.
SharePoint does not need to use Azure Active Directory for authentication. It can use a traditional on-premises or cloud-hosted Active Directory, or theoretically (starting with version 2010) can use any claims-based authentication provider aside from Active Directory.
SharePoint 2007 and 2010 could also support simple forms based authentication as well as custom authentication providers, but as noted previously, neither of those versions of SharePoint expose the REST API in question.
AD = Authentication; SharePoint User = Authorization
Azure AD is a claim provider. A claim provider is used for authentication; when you log on to SharePoint, SharePoint relies on Active Directory to determine that you are who you say you are. A user's SharePoint account is used for authorization; the SharePoint account is granted access to content within SharePoint on a site by site basis.
Information in AD vs information in SharePoint
When using Azure AD for authentication, there are usually some areas of overlap between the data in SharePoint and the data in AD.
SharePoint's user profile service is usually set up to synchronize data from Active Directory to SharePoint, so that AD serves as the master data set for things like user display name and title. However, not all information is necessarily sync'd from AD to SharePoint, and additional information can be tacked on to SharePoint user profiles.
Group Membership in AD vs Group Membership in SharePoint
In Azure AD, a user can be a member of multiple groups. Groups can include both Active Directory groups (which can be nested) and Office 365 (SharePoint) groups (which cannot be nested).
A SharePoint user can only be a member of SharePoint groups, since SharePoint does not keep track of membership of Active Directory groups. That said, a user may have access to content in SharePoint indirectly due to an Active Directory group having been granted access.
AD User Scope vs SharePoint User Scope
Unless you're working directly with the user profile service, when you work with SharePoint users programmatically, they need to be retrieved from a specific site in SharePoint. This is because each site collection has its own set of groups which cannot be used on other site collections within the SharePoint farm, so group membership is tracked only on a site-by-site basis.
Note that this means that a user's lookup ID number (which is different from their login name) may vary between site collections. This also means that a user's collection of groups will vary depending on the site from which the user object was retrieved.
An Azure AD user has no such silos.
I submitted an office 365 SharePoint add-in app for certification in the Office Store, and was told that one of the changes required is that I remove the 'Full Control' permission for the app, as it is not supported in the store. My app enables the user to create a new web site based on certain criteria. The add-in works correctly with 'Full Control' permission, but does not work with lower levels such as 'Manage'.
If the store does not allow me to use 'Full Control', what permissions or options can I use in order to still be able to create sites on behalf of the user?
Is there a different way to go about having the add-in app create sites in an existing site collection? The trigger can be user initiated, or event based.
I would love to get any ideas or solutions for this - Thanks!
The only option I can think of is to create a web service that is external to SharePoint and create the site in the service.
Here are a couple of resources that may help you:
Walkthrough: Building a Custom Web API for use with SharePoint Online
PnP Webcast - Calling external APIs securely from SharePoint Framework