Chrome's storage limits are blocking my PouchDB scenarios. I'm hoping to use Chrome's unlimited storage type. To get around the storage limitations.
To enable this storage mode, I've defined a Chrome extension granting unlimitedStorage to my domain. Here is the manifest.json:
{
"name": "Extension Granting Unlimited Storage",
"version": "0.1",
"manifest_version": 2,
"background": {
"scripts": ["background.js"],
"persistent": false
},
"content_scripts": [
{
"matches": [
"http://localhost:5988/*"
],
"js": ["content-script.js"]
}
],
"permissions": ["unlimitedStorage"]
}
This grants 100% of available storage to the extension's background.js, but there is no change to the storage limit accessed directly from content_scripts or my webpage's scripts. I'm thinking to import PouchDB into background.js and "forward" the PouchDB calls from my page to the extension via extension messaging. Similar for the result of the calls. Through this, the actual IndexedDB storage will take place in the extension's unlimited storage container.
I'm wondering if there is a better approach to solve this, or if it has been solved already. Also - whether it seems reasonable to implement as a PouchDB plugin.
Related
I have created a home site app for Microsoft Teams that renders a SharePoint communication site (sharepoint) in a personal tab by following the article Teams App with SharePoint. When I install the app in Teams desktop within the same tenant, it is working fine.
When installing the app in another tenant (fabrikam.sharepoint), where the user is added as a guest to the tenant having the SharePoint site (contoso.sharepoint), the site content does not load in Teams desktop. When accessing in a browser tab, the app starts working once I manually open the SharePoint site in a new tab.
The manifest I'm using for the app:
{
"$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.8/MicrosoftTeams.schema.json",
"manifestVersion": "1.8",
"id": "80322562-deed-42fa-88e7-373884e370f2",
"version": "1.0.0",
"packageName": "MyTeamsApp",
"developer": {
"name": "microsoft.com",
"websiteUrl": "https://MyTeamsApp",
"privacyUrl": "https://MyTeamsApp/privacy.html",
"termsOfUseUrl": "https://MyTeamsApp/tou.html"
},
"name": {
"short": "MyTeamsApp Home Site",
"full": "MyTeamsApp Home Site App for Teams"
},
"description": {
"short": "This is Tone Training Home Site app for Teams",
"full": "This is the Tone Training Home Site app packaged for Teams"
},
"icons": {
"outline": "TeamsOutline.png",
"color": "TeamsColor.png"
},
"accentColor": "#D85028",
"configurableTabs": [],
"staticTabs": [
{
"entityId": "MyTeamsAppHome",
"name": "My Teams App Home",
"contentUrl": "https://contoso.sharepoint.com/_layouts/15/teamslogon.aspx?SPFX=true&dest=/sites/MyTeamsApp",
"websiteUrl": "https://contoso.sharepoint.com/sites/MyTeamsApp",
"scopes": [
"personal"
]
}
],
"webApplicationInfo": {
"id": "00000003-0000-0ff1-ce00-000000000000",
"resource": "https://contoso.sharepoint.com"
},
"bots": [],
"connectors": [],
"composeExtensions": [],
"permissions": [
"identity",
"messageTeamMembers"
],
"validDomains": [
"*.login.microsoftonline.com",
"*.sharepoint.com",
"*.sharepoint-df.com",
"spoppe-a.akamaihd.net",
"spoprod-a.akamaihd.net",
"resourceseng.blob.core.windows.net",
"msft.spoppe.com"
],
"isFullScreen": true
}
What you're trying to do in concept is basically the same as the new "Viva Connections" capability from Microsoft, so you should consider going that route instead as it offers what you're doing plus a whole lot more. I just blogged about the background of that, with links to relevant Microsoft content, so have a look at https://hilton.giesenow.com/2021-03-31-understanding-viva-connections-app-package
In terms of the actual problem you're having though, I don't think you'll be able to get this to work on the desktop because of how the Teams app manages the current login context, but perhaps someone else will have another solution.
Currently Teams don't support the option to view a SharePoint page/site across tenants. Guest users are not supported yet either.
Summary:
When attempting to deploy a Microsoft Teams Node.JS project written in typescript to Azure servers the Teams application throws an error "There was a problem reaching this app." The application works fine when opening in a browser but is not recognized in Teams. It appears that all the manifest is setup correctly and when run in the verification of App Studio no errors are returned.
Attempted Solutions:
Attempted to match the manifest with examples given by Microsoft. Attempted to get a Microsoft teams application deployed to Azure using the examples shared by Microsoft.
Code:
Teams App Manifest:
{
"$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.7/MicrosoftTeams.schema.json",
"manifestVersion": "1.7",
"id": "dfe1fc96-d4db-4ed4-b76a-c26194928313",
"version": "1.0.0",
"packageName": "messageleapteams",
"developer": {
"name": "Real Data Consulting",
"websiteUrl": "https://messageleapteams.azurewebsites.net",
"privacyUrl": "https://messageleapteams.azurewebsites.net/privacy.html",
"termsOfUseUrl": "https://messageleapteams.azurewebsites.net/tou.html"
},
"name": {
"short": "messageLeapTeams",
"full": "messageLeapTeams"
},
"description": {
"short": "TODO: add short description here",
"full": "TODO: add full description here"
},
"icons": {
"outline": "icon-outline.png",
"color": "icon-color.png"
},
"accentColor": "#D85028",
"configurableTabs": [
{
"configurationUrl": "https://messageleapteams.azurewebsites.net/messageLeapTeamsTab/config.html?name={loginHint}&tenant={tid}&group={groupId}&theme={theme}",
"canUpdateConfiguration": true,
"scopes": [
"team"
]
}
],
"staticTabs": [],
"bots": [],
"connectors": [],
"composeExtensions": [],
"permissions": [
"identity",
"messageTeamMembers"
],
"validDomains": [
"messageleapteams.azurewebsites.net"
],
"showLoadingIndicator": true,
"isFullScreen": false,
"webApplicationInfo": {
"id": "dfe1fc96-d4db-4ed4-b76a-c26194928313",
"resource": "api://messageleapteams.azurewebsites.net/dfe1fc96-d4db-4ed4-b76a-c26194928313"
}
}
It turns out the web application was properly deployed and the manifest built correctly, however with teams tab applications hosted in Azure the loading indicator must be disabled.
I fixed this issue by setting "showLoadingIndicator": false in the manifest.json
In my opinion, if you can ensure there is no error with your code, you can check your configuration.
Next description are based on the c# sample (conversation bot)that Ms provided. And I think nodejs is similar.You can click the link and see the detail.
you have to create an Azure Ad app with client secret, and modify the 'appsetting' file to make sure the code can run in local.
ngrok is needed so you can visit your code running in local.
pls create a bot on Azure portal, enter correct appId, client secret(created in setp 1) and Messaging endpoint(get the https url after starting the ngrok,and don't forget to append '/api/messages' after the url)
now you can test your code running in local environment in web chat.
if you want to test in Teams client, you need to modify 'manifest.json' and create a ZIP file and upload your bot to Teams. Then you have to add the Teams channel in the bot created in step 3.
enter image description here
Please note if the Azure AD application created in step 1 belongs to a tenant which is different from your Teams login account's tenant, you should set the app as a multi-tenant app(when you create an app, it will ask you to choose whom are allowed to visit this app).
If there is no problem running the program locally, it will be fine after deploying to azure app service.
I am trying to setup narrow down the best possible role for monitoring data from security perspective. My needs are slightly different so I don't want to use the Security Reader role (mainly because security reader only has access to the security center items and basic resource and resource group queries). So after reading more I stumbled upon Monitoring Reader role and just Reader role. I went through the permissions mentioned in the JSON. However I am not sure if all the differences are covered in the JSON.
For instance when we talk about "Monitoring Reader"
{
"assignableScopes": [
"/"
],
"description": "Can read all monitoring data.",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/43d0d8ad-25c7-4714-9337-8ba259a9fe05",
"name": "43d0d8ad-25c7-4714-9337-8ba259a9fe05",
"permissions": [
{
"actions": [
"*/read",
"Microsoft.OperationalInsights/workspaces/search/action",
"Microsoft.Support/*"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
"roleName": "Monitoring Reader",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
The privileges are basically the same expect that I can query the logs. Compared to the Reader role which is
{
"assignableScopes": [
"/"
],
"description": "Lets you view everything, but not make any changes.",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7",
"name": "acdd72a7-3385-48ef-bd42-f606fba81ae7",
"permissions": [
{
"actions": [
"*/read"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
"roleName": "Reader",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
Now from a logical standpoint if both the users are able to execute */read doesn't Reader role automatically qualify to query the logs? If not, how is it different? Also which role is superior in terms of access to readable data?
Reference : https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#reader
PS : I do know about custom roles but want to understand built-in roles better.
Now from a logical standpoint if both the users are able to execute */read doesn't Reader role automatically qualify to query the logs?
They are both able to execute */read, but Reader cannot query the logs.
If not, how is it different?
The difference is Monitoring Reader can execute the Microsoft.OperationalInsights/workspaces/search/action and Microsoft.Support/* actions.
Also which role is superior in terms of access to readable data?
From the actions scope of the role definition, obviously the Monitoring Reader is superior in terms of access to readable data.
My App Service in Azure is free. In portal.azure I can watch Quotas and monitor if I'm closing to the limits. Is there a way to show these Qoatas to users without the access to the portal.azure? Those users are in the same Active Directory where the app rests but they have no knowledge on how to use portal.azure.
Edit: I've added the screenshot asked by #Jay
You could let them use the REST API - App Service Plans - List Usages, click the Try it button to login, specify the parameters then run.
This part in the response like below is that you can see in the portal.
{
"unit": "Bytes",
"nextResetTime": "9999-12-31T23:59:59.9999999Z",
"currentValue": 20480,
"limit": 53687091200,
"name": {
"value": "FileSystemStorage",
"localizedValue": "File System Storage"
}
}
As of yesterday I added a webapi and a native app to my Azure AD.
Yesterday I was able to download the WEBAPI's manifest file to add appPermissions (for delegating permissions to the native app).
Not there's no longer any appPermissions located in the manifest file, it has changed. I have tried to add new apps, and even a new AD.
Now theres only appRoles there.
Does anyone know why this is, and how I could solve this so i still can delegate permissions?
Might this be the new thing to use?
oauth2Permissions": [
{
"adminConsentDescription": "Allow the application full access to the service on behalf of the signed-in user",
"adminConsentDisplayName": "Have full access to the service",
"id": "23906603-82b7-4471-afbd-b6bcf2fe7b1a",
"isEnabled": true,
"origin": "Application",
"type": "User",
"userConsentDescription": "Allow the application full access to the service on your behalf",
"userConsentDisplayName": "Have full access to the service",
"value": "user_impersonation"
}
],
#Simon Agren is right, and that new oauth2Permissions worked for me. Just download an old existing Maninifest and you will see how it now uses the oauth2Permissions instead of the appPermissions. Remember to create a new GUID for the id attribute.
I also turned surprised when I saw that this morning :)
Cheers.