I have backend(e.g. https://api.myapp.com) based on the Azure Mobile services(AMS), now I need
1. add one or two apis that doesn't require to be on AMS e.g. an heartbeat controller to check that service is online or not, that doesn't require Zumo Auth
2. an ASP.net MVC page(e.g. https://www.myapp.com) that explains about the application
Can I use the existing AMS to do this, I tried to add plain asp.net web api, but getting error that end point doesn't exist
Are you truly using Azure Mobile Services and not Azure Mobile Apps? You generally cannot have a custom domain on Azure Mobile Services. Since you mention ZUMO Auth 2, I'm assuming you mean App Service Auth and thus Azure Mobile Apps.
I'd recommend taking a look at Azure Functions for any APIs that do not require ZUMO. However, you can just add a custom API to your service. I cover all the options for you in my book - http://aka.ms/zumobook - chapter 4.
As to a service controller for checking heartbeat. If the intent is to ensure that the service is alive, then just create an unauthenticated custom API that tests the database connectivity (maybe does an SQL command to get the count of rows in your main table) and returns success or failure. You can then use Azure Functions, Azure Scheduler or OMS to do a query of that custom API.
Related
I have an idea to make my apps to be Backend Driven and for this reason I want to query Firebase Remote Config for some values which has some condition properties when they should be applied (for example: parameter show_banner should be applied only for Country: Portugal) and I want to have the possibility to use A/B testing for such scenarios.
In other words I want my backend microservice to make requests to Firebase Remote COnfig (with A/B testing feature) on behalf of mobile applications (I can have information about the version, country, mobile id etc.. in the backend). Is there any REST APIs that can help me achieving this ?
The REST API for Remote Config only allows managing the template, so the equivalent of the operations you can perform in the Firebase console.
There is no public REST (or other server) API to get a set of remote config values for a specific device. That operation is only possible through the client-side SDKs.
I have a backend system built in AWS and I'm utilizing CloudWatch in all of the services for logging and monitoring. I really like the ability to send structured JSON logs into CloudWatch that are consistent and provide a lot of context around the log message. Querying the logs and getting to the root of an issue is simple or just exploring the health of the environment - makes CloudWatch a must have for my backend.
Now I'm working on the frontend side of things, mobile applications using Xamarin.Forms. I know AWS has Amplify but I really wanted to stick with Xamarin.Forms as that's a skill set I've already got and I'm comfortable with. Since Amplify didn't support Xamarin.Forms I've been stuck looking at other options for logging - one of them being Microsoft's AppCenter.
If I go the AppCenter route I'll end up having to build out a mapping of the AppCenter installation identifier and my users between the AWS environment and the AppCenter environment. Before I start down that path I wanted to ask a couple questions around best practice and security of an alternative approach.
I'm considering using the AWS SDK for .Net, creating an IAM Role with a Policy that allows for X-Ray and CloudWatch PUT operations on a specific log group and then assigning it to an IAM User. I can issue access keys for the user and embed them in my apps config files. This would let me send log data right into CloudWatch from the mobile apps using something like NLog.
I noticed with AppCenter I have to provide a client secret to the app, which wouldn't be any different than providing an IAM User access key to my app for pushing into CloudWatch. I'm typically a little shy about issuing access keys from AWS but as long as the Policy is tight I can't think of any negative side-effects... other than someone flooding me with log data should they pull the key out of the app data.
An alternative route I'm exploring is instead of embedding the access keys in my config files - I could request them from my API services and hold it in-memory. Only downside to that is when the user doesn't have internet connectivity logging might be a pain (will need to look at how NLog handles sinks that aren't currently available - queueing and flushing)
Is there anything else I'm not considering or is this approach a feasible solution with minimal risk?
I have seen mentioned that there is actually a 1000 app hard limit to Firebase projects as it is the OAuth 2.0 Client IDs that have a limit of 30 and that these can be deleted if not needed.
I have removed the OAuth Client ID for my app from here https://console.developers.google.com/apis/credentials
My app is a hybrid app (Ionic) and uses firebase auth with email/password via the web app not native one so it appears to work fine.
I am assuming this means I am home free and can add up to 1000 apps if I manually delete the OAuth 2.0 Client ID each time?
I am looking at adding Google and Facebook sign-in on the hybrid mobile apps using a native implementation (just for the google/fb auth) soon would this be something that I would need the native app OAuth 2.0 Client IDs for? Is this just used for Google Auth?
If so I guess this would restrict me back to 30 apps but I could use the web Google Auth (although the UX is not as good).
I will also be using Firebase Cloud messaging if that is related at all.
I am not familiar with OAuth 2.0 Client IDs so any help is appreciated as I don't want to go down this route but find a problem later on once my product has gone to market.
Note: I have read the recommendations from Firebase that each tenant / customer / label should have its own project. This is not how I want to implement my platform as the data is shared between tenants as users can belong to multiple tenants. Plus making a project per tenant seems crazy if I have up to 1000 tenants.
Some of the tenants but not all will have their own branded app. Same app with different branding and in different app store accounts.
https://firebase.google.com/docs/projects/learn-more#multi-tenancy
It appears the limit for apps has now been reduced to 30.
https://firebase.google.com/support/faq/#apps-per-project
If you need more than 30, the above FAQ entry states:
In the rare case your project requires more than 30 apps, you can request an app limit increase. Your project must be on the Blaze billing plan to make this request. Visit the Google Cloud Console to make your request and have it evaluated.
I need advice as i am new in .net and azure, i am creating a architecture for a project which has its mobile application, web based admin panel and Website.
I am planning to host every thing in Azure. I am creating application in Xamarin. Application needs to have Push Notification, Offline Sync etc, features provided by Mobile App Services (Controller inherited from TableController).
I want to create 1 database which will be used by all 3 modules. I have already created a Mobile App Service and Database. Mobile application is using it as it was supposed to. Now i want to create a website and Web based admin panel and use the same database. Is this possible ?
What is the best way? Should i create a web project and perform operations on data via REST API? and use this API for Mobile Apps and Web based Backend?
I am really confused between different services from azure and which one to use. Should i use .Net Core or .Net. I need to know the best way to do it.
Edit 1 :
So far this is what i have done and i need to know if this will work fine in future when project get complex. I created database and back end via Azure Mobile App. Now i have created a .net MVC website and used RestSharp for CRUD operations in it. I have used the following code to perform the operations. Note the /tables/ part in the request url.
var client = new RestClient("http://xxxxxxx.azurewebsites.net");
var request = new RestRequest("/tables/request?ZUMO-API-VERSION=2.0.0", Method.POST);
string data = "{\"createdFor\":\"535862cf-e2b3-41de-99f9-88c47a77750c\",\"status\":\"IN_PROCESS\",\"createdBy\":\"7108147e-c11c-4d78-ac3d-d5d6c5eb78d0\",\"description\":\"Master room 5 door produces strange sound when opened or closed\",\"title\":\"Door Sounds Strange\"}";
request.AddHeader("Accept", "application/json");
request.Parameters.Clear();
request.AddParameter("application/json", data, ParameterType.RequestBody);
var result = client.Execute(request);
Console.WriteLine("Content " + result.Content);
Get and post operations works fine. Is this a good way?
Thanks in advance
As the official document mentions about Mobile App Features:
Authentication and Authorization (AAD,Facebook, Google, Twitter and Microsoft Account,Custom authentication)
Data Store (SQL Database, Azure Table Storage,etc)
Offline Sync
Push Notifications (Client SDKS seamlessly integrate with the registration capabilities of Azure Notification Hubs)
Client SDKs (A complete set of Client SDKs that cover native development, cross-platform development,etc)
Per my understanding, if the build-in features provided by mobile app could totally meet your requirement, then Mobile App is better for you and it would save your time. For Web API application, you need to do all stuff by yourself.
Now i want to create a website and Web based admin panel and use the same database. Is this possible ?
I assumed that you could create a Azure Mobile App application (Mobile App) and a web application (Azure Web App) under your solution, and you could extract the DbContext related classes into a shared class library.
Should i use .Net Core or .Net. I need to know the best way to do it.
For choosing between .NET Core and .NET Framework, you could refer to the official document about choosing-core-framework-server.
UPDATE:
Can you please take a look at edit 1, and suggest if this is the right way or it can create a problem.
Your code would work fine, since the mobile client SDK just wraps the common processing as your provided.
Note:
For accessing only by authenticated user, you need to add x-zumo-auth header with the authenticationToken after you logged.
Additionally, for your MVC application to retrieve the data from your mobile app (need authentication), you need to log with your mobile app and retrieve the authenticationToken for your subsequent requests against your mobile app. At this point, except for Custom authentication, otherwise you could only leverage Client-managed authentication and use JavaScript client library for Azure Mobile Apps in your MVC application for logging to mobile app and retrieve the authenticationToken, then you could send request from your front-end or pass the token to your back-end. For SPA, you could use both Client-managed authentication and Server-managed authentication.
Moreover, Adrian hall has wrote some useful tutorials about developing against azure mobile app, you could refer to Adrian hall's book.
UPDATE2:
For custom authentication using an Identity Database, you just pass the username and password to your mobile app, then it would validate the user info and generate the authenticationToken. While for Auth0, you firstly login with Auth0 provider, then pass the token to your mobile app.
My mobile application has its own signing up and sign in option with username and password.
For the connection Username-Password-Authentication from Auth0, it would manage the users for you, while using an Identity Database, the users would be stored in your storage and you need to manage them by yourself.
Per my understanding, both approaches could implement the custom authentication for you, but you need to choose the better one that matches your scenario.
We are looking into authentication/authorization for a mobile reporting app which consumes hourly/weekly/monthly commercially sensitive data over the wire using an internally provided RESTful web api service running within the MS Azure Cloud.
Stormpath's offering looks interesting in that it would appear to provide some heavy lift for the whole identity management side of things, registering users, authenticating them and producing JWT tokens etc.
Otherwise, we would have to write our own auth/user db tables and have some management overhead with that.
What I am not fully clear on is where our current unsecure, unauthenticated prototype API served up by Azure would need to intersect with Stormpath.
Can anyone, especially those familiar with Stormath elaborate on this?
I get that all the user registration, password recovery use cases would go via Stormpath and I am guessing that JWT token creation for a user would require our existing service to talk to Stormpath. Would the validation of tokens within the HTTP(S) headers of our RESTful calls be done by our Azure service locally (via some code plugin) and if so is that validation done locally or does each RESTful call have a side effect of proxying calls to Stormpath API to validate the goodness of a token?
I guess I am sensitive to performance issues regarding the whole token validation step within the Web API pipeline.
I've read elsewhere that Microsoft themselves have an offering, namely Azure AD B2C which it seems is not production ready for regions outside of US/North America as of yet.
Is that something else we should consider as an alternative to an outsourced offering like Stormpath?
One thing which looks attractive about something like Stormpath is the possibility of two factor authentication.
Without having gone into too much analysis yet, a typical use case scenario would be that sign up or password recovery would mandate that an SMS was sent to the user's preregistered smartphone number to provide a stronger validation that they (and their pre-registered device) are the intended user of the mobile app which uses the RESTful service to consume and visualise commercially sensitive data.
I work at Stormpath on our .NET libraries.
What I am not fully clear on is where our current unsecure, unauthenticated prototype API served up by Azure would need to intersect with Stormpath.
Stormpath acts as your API's source of access tokens. When someone using your mobile app needs to log in, your backend API uses Stormpath to generate an access token, or the mobile app talks directly to Stormpath to get an access token. Either way, the token allows the mobile app to make authenticated requests to your API.
Would the validation of tokens within the HTTP(S) headers of our RESTful calls be done by our Azure service locally (via some code plugin) and if so is that validation done locally or does each RESTful call have a side effect of proxying calls to Stormpath API to validate the goodness of a token?
The access token (JWT) integrity can be validated locally using middleware like UseJwtBearerAuthentication in ASP.NET. For more security, you can send the token up to Stormpath to be verified even further (for revocation and other cases), but the tradeoff is a network request. Local (fast) validation is the default, but we give you both options.
I've read elsewhere that Microsoft themselves have an offering, namely Azure AD B2C which it seems is not production ready for regions outside of US/North America as of yet. Is that something else we should consider as an alternative to an outsourced offering like Stormpath?
Using either Stormpath or Azure AD B2C is "outsourcing" your identity and user management. The benefit is that you don't have to write it yourself, and you can focus on writing your business and app logic instead. The features are similar, although Stormpath is a little more flexible on the mobile side of things (since you aren't forced to use a browser/page-based flow).