I want to use some of the APIs provided by Firefox OS. But many APIs are accessible only for privileged and certified apps. Firefox OS documentation suggests (as far as i understood) that "the apps which are deployed in marketplace are privileged apps". But how can i deploy an incomplete app to the marketplace without even testing the functionality of those APIs? Is there any other way to access those APIs? Thanks in advance
You can test your app using the FirefoxOS Simulator:
https://developer.mozilla.org/en-US/docs/Tools/Firefox_OS_Simulator
Depending on the APIs you're testing the simulator can help. Some aren't available due to hardware not being available on a desktop device.
Also, if you are developing a "hosted app", you have access to APIs which use web permissions. If you need more than that you would need to create a "packaged app" with type=privileged and specify which permissions you want access to in your manifest. This is described here: https://marketplace.firefox.com/developers/docs/packaged
The app permissions table will tell you if the APIs you want required hosted, packaged, or certified (only available shipped on device).
Related
I have azure app service where I am running a tomcat application, is there a way / or any in-build anti-malware option is available if not how to implement threat protection in this app service
Azure App Service uses the same Antimalware solution used by Azure Cloud Services and Virtual Machines but it is completely managed by our Engineering team on regular basis.
Also as a PAAS service we currently donot provide anti-malware scanning as a customer facing service. The implementation of A/V on our service has gone through, and will continue to go through, changes as we tune it for its primary purpose. Its primary purpose is to protect the service itself (PAAS) from viruses.
If you have custom requirement of having providing anti-virus scanning then IaaS VMs should be the choice as they have installable extension for virus scanning and the choice of different A/V technologies.
You can check the documentation in the below link:
https://learn.microsoft.com/en-us/azure/security/azure-security-antimalware Screen shot of the information under Architecture section of the link.
https://learn.microsoft.com/en-us/azure/app-service/app-service-security-readme
For now, there is no native virus scanning / anti-malware feature on Websites. However you could implement it with third party API like ClamAV or the extension in Azure App Service named with Tinfoil Security.
There are two ways to integrate Tinfoil Security to you app and this is the introduction, first you could refer to this doc ,I tried this way however It show Failed to purchase. So maybe you could try another way. Under Development Tools in your App choose Extensions , click Add button then Choose Extension, on the list there is a Tinfoil Security , that's what we need. I tried this way, it could be integrated to my App.
The chrome web store support 3 different app types: extensions, hosted apps, and packaged apps. Extensions are for apps that have minimal UI and primarily extend the functionality of Chrome. Packaged apps can run in a tab, can access the Chrome API, and run in the background. Hosted apps run in a tab and require an internet connection to load the page from the host.
But what kind of apps does the G-Suite marketplace support? I noticed that apps installed in the marketplace should up differently (i.e. they show up the nav bar launcher when logged in to Google Apps, not in a Chrome tab) so does that mean there are a different app type? And when Chrome removes support for it's hosted and packaged apps does that also affect the same types of apps in the G-Suite marketplace?
Since your question is more about G-Suite apps but it is worth to know little about other things in chrome store as well.
1. Chrome Extensions:
Chrome extensions are tiny applicatons with minimal ui. You can access all the chrome APIs that you need to create an extension. Take a look at the manifest file or jump over to top section to start learning.
Examples: add blockers and save bookmark extensions
2. Chrome Hosted Apps/ Packaged Apps:
These are Standalone apps with full UI. If you want to give users more interaction or if your app is more complicated with multiple views or it does not interact with user visited web pages then you can choose to create a chrome app otherwise go with extension. You can access all the chrome APIs that you need in your application. One thing to note about hosted Apps, they can't access chrome APIs since they hosted on other servers rather than local to user browser. Here is the manifest file or jump over to top section to start learning.
Examples for Packaged Apps: Rest Clients, Hosted Apps: Messenger apps
If you look extension manifest file and apps manifest file they look identical except you explicitly need to specify it as an app.
So what are chrome APIs: In general you want to access users top most visited websites, there you go you have chrome.history API. You need to specify the permissions in your manifest file before you use them.
Before you choose what you want to create take a look at here. It is just a decision logic which explains which fits for you.
https://developer.chrome.com/webstore/choosing
3. G-Suite Apps:
Google suite Apps are little add-ons to automate the tasks of Google's 11 Cloud Apps. Those apps are Google Docs, Calendar, Drive, Gmail, Translate, Maps etc.Quick intro here.
Since they directly included into google apps so that they can be accessed whenever you use those apps with any browser. You are going to use Javascript (known as App Script here but not much difference) and bunch of google APIs to build your g-suite apps.
Note: They are specifically designed for Google products.
Here are some of your questions:
what kind of apps does the G-Suite marketplace support?
G-Suite apps currently supports product management and education related apps.
I noticed that apps show up the nav bar launcher when logged in to Google Apps, not in a Chrome tab?
Since they are built for google cloud apps they live right inside the apps. You can access them from menu bar. A good example would be a spell checker for docs.
When Chrome removes support for it's hosted and packaged apps does that also affect the same types of apps in the G-Suite marketplace?
As of now, Chrome said they will remove support for in browser chrome apps after mid 2017. But they never told anything about chrome extensions and Google suite apps. So they are safe and Google suite apps are pretty new.
We have built a simple mobile app that connects to ASP.net Web-API 2.
We would like to use Microsoft client SDK for it's offline sync support.
Now that Azure Mobile Apps support custom authentication we could actually take the leap.
I want to know out if the offline sync SDK absolutely requires us to use Azure Mobile App or Azure Mobile Services.
Microsoft documentation is full of how-to guides but does not explain what happens under the hood. The best I could understand, both are just OData rest API's and swagger for documentation.
Can the Azure Mobile Client SDK work with API server created on top of ordinary ASP Web-App, outside Azure?
What is it about the Azure Mobile App that makes the magic happen?
Vladmir,
On top of OData, in order to support features like soft delete, offline sync and others, the Azure Mobile Client SDK expects the server to implement a certain protocol. So although the answer to your question:
[does the] sync SDK absolutely requires us to use Azure Mobile App?
... is no, and in theory, you could implement your own API, but I would recommend against doing so, since (among other reasons) even if you manage to implement the expected conventions and behaviors, this will become a maintenance challenge down the road if you need to upgrade the client SDK to take advantage of bug fixes and/or new features.
The good news is that with the latest release of the Azure Mobile Apps server SDK, adding mobile capabilities to an existing ASP.NET Web API application is trivial, and you should be able to enable the scenarios you're looking for simply by adding the appropriate Table controllers. So you can just enhance your existing application and not have to develop and maintain the Azure Mobile Apps specific logic yourself.
About your last question, since both, the client and the server SDK are both open source and developed in the open, you can look at what what makes the magic happen here:
https://github.com/Azure/azure-mobile-apps-net-server
https://github.com/Azure/azure-mobile-apps-net-client
I hope this helps!
The answer for your first question: Yes the SDK can be used in any Server API you have since it will be your entry point to work with Azure Mobile Services.
The Azure Mobile app creates a mobile services instance which has push notifications and SQL tables to store all messages you would like to send with the capability to customize the message as needed. Also it creates a notifications hub instance under the hood to manage notifications for all mobile platforms. Azure mobile apps provide offline capabilities through native sync services between db on your devices and the server when connectivity is present.
Feel free to ask more questions to have a full understanding on How mobile apps works.
Hope this helps.
I have a WebAPI back-end for a mobile, and want to host it in Azure.
I am having a hard time figuring out the real differences between AMS and Websites.
All the articles I read about the subject talks about changes and benefits in general, and I want to understand specifically which new features AMS provides, and the benefits of hosting in AMS.
Authentication
In AMS I see the "IDENTITY" tab in azure portal. From what I understand, those 3rd party configs allow me to authenticate my users easily with google,FB etc. But this is just making the process more convenient and configurable via UI. In Websites, I can achieve the same functionality pretty easily using code from ASPNet.Identity and OWIN libraris.
Push Notifications
Again looking at AMS in the "PUSH" tab, I can see two mechanisms. The Notification Hub and 3rd party section.
The Notification Hub is nothing special to AMS, and I can get the exact same functionality when hosting in Websites.
The 3rd party section allows me to configure credentials to push services from Apple and Google (APNS,GCM...) and together with libraries in AMS namespace I can easily write code to communicate with those services.
But When hosting in Websites, in my back-end I can use open source libraries. For example, Moon-APNS to talk to APNS.
Scale
As far as I understand, both Websites and AMS allows the same scale functionality (One calls it Units and the other Instances).
Are there any big differences I missed?
Are any of the claims I made are incorrect?
It would be great if anyone could shed some light on the matter, specifically addressing all the 3 issues (Auth,Push,Scale).
That's a question I often get when I present Mobile Services at user group events.
For a .NET developer, there's nothing really special about Mobile Services since everything it offers, you can do it with a Website.
Mobile Services really shines for non .NET developers since you can have a complete mobile backend by writing scripts running on Node and Mobile Services abstract all the database and REST complexity.
I will likely get downvoted since I'll express a personal opinion but anyways: I see no obvious reasons for using Mobile Services if you're coding a .NET backend.
I think you are exactly the target customer for Azure Mobile Apps. You will get all of the power of having your own Azure Website (now rebranded as Azure Web App), with the additional convenience and client libraries of Mobile Services.
One feature of the client library that you may not have noticed is the cross-platform offline data sync capability. That's usually hard to build on your own, and we have an implementation that's conceptually consistent across all client platforms. (Plus, if you use Xamarin, you can share code between your client implementations.)
To be clear: Azure Mobile Services is NOT deprecated, and will not be until long after GA (general availability) of Azure Mobile Apps. Azure Mobile Apps is currently in preview.
The other big benefit of Mobile Services that you haven't mentioned is the client libraries for Android, iOS, Xamarin, and Cordova. If you already have a REST client library in your app and don't need to worry about multiple client platforms, then Azure Web Sites sound like a good way for you to go.
AMS by itself is built on top of Azure Websites. So you can actually implement everything in an Azure website that is available in AMS.
However, the good thing about AMS is that it allows you to quickly build the backend for a mobile app with CRUD operations, authentication/authorization and also provides client side libraries for different type of clients e.g., HTML, C#, etc. so we don't have to manually make the HTTP calls.
If you have need to implement the above functionality in Web API, it is quite an effort. Isn't it?
I wonder what is the security level for azure hosted websites. Is it Medium/High or Full?
They run in Full Trust (source).
However, they use a Sandbox mechanism, and as a result some APIs are not available (e.g. Sockets using IPv6), or do not work as expected (for example, the Socket.Available property is unavailable, which restricts the use of some libraries such as NetFTP).
If you are considering using WA Websites for scenarios in which .NET Security might be a problem, I suggest you to get in touch with Microsoft support to ensure that the specific features you may need are supported on this environment.