I have a Push-Notification service set up that I need to migrate because IBM is closing the old service, with this service I have a Mobile Data service with many users. Then I created a new app and created the services: IBM Push Notifications, Cloudant NoSQL DB and Mobile Client Access. How can I bring the old users to the new app with the new push notification service?
I am truly sorry to say it's too late to migrate using Mobile Data or Push resources as the applications have been deprecated since December and finally taken down as of today in accordance with the notice IBM put out towards the end of last year. Additionally you should have received an email around March encouraging engagement with our support team to assist in migrating your application. Regretfully, due to the cessation of the old services, the data within those services is now inaccessible.
Without these resources to migrate I fear your best option would be to use the new backend services within your application and have users register to the new push service recreating your push subscribers and using the new Cloudant NoSQLDB platform to manage your data. Apologies for the inconvenience the deprecation has likely caused, please let us know if we can assist any in utilizing the new suite of mobile services.
Related
The desktop application I am developing (C#/.NET, WPF) uses a feature which requires connection to IMAP- and SMTP servers of the user. I am using a package called MailKit for this. Some of our users are using Microsoft365 and will require modern authentication in the future, as opposed to the basic authentication they are using right now. This is supported by MailKit and I am able to authenticate using OAuth2.0.
However, this requires a client secret, which expires after a certain amount of time (e.g. two years) after creation in Azure. This client secret is compiled with the application, after which the application is distributed. Does this mean the users need to update their installation at least every two years, so I can supply a new client secret? This is undesirable to our users. The best solution for me would be if I could refresh expired client secrets without the user having to perform any action.
Perhaps its a good idea to force the users to upgrade the software after two years? Like forcing them to buy an upgrade (business opportunity) or as a way to distribute fixes and updates to the application?
Most applications today you do update at least every year?
So it seems that in the spirit of having documentation all over the place, docs.microsoft has once again taken the cake.
Looking into sending push notifications, I came across these two pages:
https://learn.microsoft.com/en-us/appcenter/sdk/push/uwp
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-windows-store-dotnet-get-started-push
Notice how there's no reference from either page to the other.
So I tried searching Google, doing similar searches to the title of this question, only to find little more than the above two pages.
Which brings me here, with the following question:
What is the relationship (and/or difference) between App Center Push and Azure Notification Hub?
They don't have a reference from either to the other because they are two completely unrelated solutions (except for the fact they solve the same problem).
Both allow you to setup a cross-platform push notification infrastructure for your mobile app, but App Center is free, specifically built for iOS, Android and Windows notifications and requires less setup, but gives you a bit less control over how the notifications look. However it makes it easier to segment notifications based on analytics data. Notifications Hub is a Azure service, so you need a Azure subscription and you need to build a backend to make it work. It takes a more work but you have more complete control over the notifications.
The awesome James Montemagno made a nice summary article comparing the two options.
I think its important to add the fact that App Center Push, Auth and Data are now being retired, despite Push being a fantastic offering IMO:
https://visualstudiomagazine.com/articles/2020/02/14/app-center-mbaas.aspx
"We are discontinuing efforts in the Auth, Data, and Push services and
working to retire these preview services in App Center," said John
Wargo, principal program manager for Visual Studio App Center. "With
this change, we will focus App Center on delivering a world-class
mobile and desktop DevOps experience. We will also work together with
Azure teams to help migrate developers to the native Azure services,
and ensure that Azure continues to be a great platform for your mobile
apps."
There seems to be no full migration path at time of writing, but there is the hint this will be handled mostly for existing users -
https://learn.microsoft.com/en-us/appcenter/migration/push/
We don’t expect customers to manually migrate from App Center Push to
Azure Notification Hubs; so before the service shutdown, we’ll provide
detailed instructions for how to streamline your app’s migration from
App Center Push to Azure Notification Hubs.
We recently moved an Azure subscription from one tenant to another while consolidating all our subscriptions in one tenant. Unfortunately, this broke Managed Service Identity for all our Web Apps, and we are now hesitant to move our remaining subscriptions for fear of having to provision new Web Apps in order to get MSI working again.
Is there a way to prevent this from happening, or at least a way to delete or reset the identities created by MSI so we can recreate them? That would lead to a little bit of downtime, but that would be preferable to having to come up with new names for all the Web Apps, as that was ultimately the solution we found to getting new identities.
Of course, we would prefer to avoid any downtime at all, but I realize that moving a subscription between tenants (and their directories) is tricky.
Filip, thank you for reaching out. We're currently investigating how to make the subscription move a smoother process for MSI enabled resources. Please send me a mail, and we can chat further: ArLuca#microsoft.com
I'm a newbie with ASP.NET Web API and I heard so much about it that, it's the new industry standard and all, I've decided to build a regular hotel management system with it. I created some models and generated controls and created database using code-first migration. It all was tough at the beginning but now I've got hold of the essence. It's Awesome.
Now I'm stuck at the user management level. According to Web API spec there are options to manage access to resources like basic, Forms, integrated Win and OAuth. And also something about 2-legged and 3-legged which I understand are all authentication options which involves another data source or app (may be not the right terms) that will handle the authentication on behalf of the Web API I build.
Since my application is simple (for now), I was thinking is it possible to allow the Web API to include the necessary authentication, for example authenticating (user) and authorizing (role) before giving access to the data, thus seliminating the "LEGGED" dependance but at the same time it is open to allow 2-LEGGED and 3-LEGGED implementation in the future if I wish to.
From what I've seen and read the Web API is not ideal for a system like what I'm developing. Hope I'm wrong coz I find it awesome in terms of a service that can be consumed by other systems.
In my mind the big picture for the system is to allow customersI and third parties to access
hotel information via web and smart phones to check room availability and book rooms
restaurant information ...
hotel events, spa..etc
Please advice, to achieve this, how do I go about implementing authentication and authorization?
I have a c# window form application (which is basically a game).
And an ASP.NET Website. the window form application has a database with a table that contains the username and his cash. The asp.net database has a table that contains the username and his cash.
Now I want to sync between to the two servers. Once I get point in my game, It'll also update the database of the asp.net site.
You could expose a web service endpoint in the web app which the Windows app can call to post updated user stats.
Likewise a web service could return updated stats to the Windows client for synchronization into the Windows app database.
As Uwe Keim mentions, the web app can only expose a service or data feed that the Windows client must poll regularly. There is no feasible way that the web app can call the Windows app directly.
Why not host the database on one location and let the game/website connect to your DB through a web service? This way you only need one database with all the relevant data compared to two. You'll have to recode some parts of your website and game but in the long run this is more optimal than two databases with the same data.
More information regarding web services can be found here.
You can develop some kind of an API (Service) in the web application and do the sync between the two apps. You are talking about two servers at the end of your post. What kind of servers are you talking about? Is the game available in standalone also? If not, can't you think of having a single DB for both of them?