I have implemented In-App Purchase in an old ASP.NET project. But the problem is if the subscription got expired or auto-renew somehow got failed. How am I supposed to update at the server end? I don't know what to use 'web hooks' or any 'cron job' or any other method for this so that the receipt verification also got updated at the server end. This is an old ASP.NET Web API project. I have an azure cloud subscription for this project. I do not want to use any third-party library.
Related
We have a hybrid Active Directory scenario - an on premises Active Directory server synced with an Azure AD tenant.
We are in the process of migrating our on premise Exchange email accounts to 365.
We have a SPA (JavaScript) that displays calendar events retrieved from a dotnet core web API.
The web API only allows access to users in a specific AD group.
The SPA uses the Fetch API to call the web API with credentials.
The web API currently uses EWS to connect to our on premise Exchange server to read calendar events, using its app pool identity.
The above systems have been developed in-house and run on our internal servers.
We want to update the Web API to read calendar events using the MS Graph API, on behalf of the user. We would like to use the simplest available solution.
We have tried to use the AcquireTokenByIntegratedWindowsAuth method but receive the following error: 'Integrated Windows Auth is not supported for managed users'. My limited understanding of why this doesn't work is because we do not have an ADFS on premise.
One of the Microsoft samples shows a SPA acquiring an access token and passing the token in the header as part of the web API call. This would require us to update the SPA and web API code. We're willing to do that if it's the only solution, but I am hoping someone might offer an alternative where we only need to update the web API.
I'm working on a project created using Identity Server 4 for authentication, an API application that handles all the data and business logic and a client web app.
The IdentityServer project uses a different database for managing the users of the app and the API project has a copy of that table that gets synced with the one from IS when the user logs in.
The problem I'm facing is this:
When a user confirms his email the information is handled by IS but until his first login, the user appears to have his email unconfirmed in the API project.
How can I solve this without coupling the IS project to the API one?
I see various way to handle this.
Use messaging system to sync data (Users and it't update) between both the database.
Access DBContext of API project into the IS to manage users.
Or even simply have api to give updates to API project upon first login.
C# ASP.NET web page that has requirement to MFA to Azure SQL Database.
I have working in development environment.
When I deploy to web server error is received of...
"Showing a modal dial box or form when the application is not running."
I understand why it doesn't work, but how do I get a redirect to work against Azure SQL Database to get a token for the SQL Connection ?
Best answer was:
Acquire AAD token using ASP.Net web forms
What am I missing to make MFA to Azure SQL work in asp.net?
result = await authContext.AcquireTokenAsync(
parameters.Resource, // "https://database.windows.net/"
_clientId,
_redirectUri,
new AD.PlatformParameters(AD.PromptBehavior.Auto),
new AD.UserIdentifier(
parameters.UserId,
AD.UserIdentifierType.RequiredDisplayableId));
Follow up, I have the basics of this worked out.
Enable HTTPS (this was an on-prem, internal use web app, was not https, it is now).
Ensure .net 4.7.2
Ensure URI()'s match azure application registration (was missing this)
The redirect and URI back are causing me to change the design and flow of the web page, but that's a side effect of the MFA requirement.
Will post some follow up code example once i have it working the way it should, but a quick test has it working, much easier in windows application as opposed to a web app.
I have an ASP.NET MVC app, running as Azure Web App.
I use pre-authentication/EasyAuth, and for 5 deployment slots it works fine. Each of them has their own Azure AD App Registration.
But the production site (not a deployment slot, root of the app) throws an error when after logging in, at the /.auth/login/aad/callback path:
I have compared Azure AD App manifest with one that works, and the only difference is the names, description and URLs - as expected.
Using Kudu to view an error, it seems to come from the EasyAuthModule:
So, basically this was an issue with the App Registration used, were created from another deployment slot.
Even though Authentication / Authroization for the web app was set up as Express, the correct App Registration was selected - it turns out it did not get the Client Secret transferred from App Registration to the Web App (in my case, it had the wrong key):
To fix it, you can switch to advanced as shown above, open the associated App Registration and create a new key:
The key is not shown until you save, and is only shown once. Copy it, and insert it into the Client Secret input of the Web App.
After saving all the blades, it is possible to switch back to Express auth. setup and the key will remain.
As I cannot comment I'll add my case as an answer in a bit more detail than I would have to a comment.
I had the exact same error messages From Easyauth in an ASP.NET MVC app running as Azure App Service Web App.
The initial error message was just "The page cannot be displayed because an internal server error has occurred." And via FTP and/or Visual Studio Server Explorer and/or Cloud Explorer I could check the real error page after setting the detailed error messages on from App Service Logs. Those errors were the same as with MartinHN got using Kudu.
So in the more detailed error the predominantly shown 500.74 error originally pointed me to the wrong direction (MFA). But Request Url (.auth/login/aad/callback ) where the error message indicated the internal server error was occurring in, led me to this SO question.
In my case though I had the Advanced Configuration already selected in App Services Active Directory Authentication. And the client secret key was not just wrong. It turned out that the client secret had expired. But it wasn’t obvious to me as I don’t have access to the AAD. I had to contact a separate AD team to check the secrets.
So expired client secret (keys) can also cause this very same error.
I am using the ADAL3 for authenticating on the Azure AD app. Then I use the AuthenticatedClient Async for logging into the Azure backend.
What is the correct strategy for consuming Azure backend and working with token? Do you call AuthenticateClientAsync before each call to the backend to be sure that if the session expires on the backend the token will be used to start the session automatically? What append if the memory save token is expired, do you manually ask users to login again?
Someone has a sample of an app that popup a login page then call some service and popup a new login page if needed?
Thanks for your help.
According to your description, I assumed that Azure Mobile Apps would be the approach for you to work as your mobile backend. And you could authenticate your customers with AAD and leverage the client SDKs provided by Azure Mobile Apps to communicate with your azure mobile app backend.
I would recommend you follow this tutorial for creating your Azure Mobile App and download the sample project for getting started. Then, you could configure your mobile app to use AAD login, details you could follow here. Moreover, more details about how to use the client SDKs for Azure Mobile Apps in your xamarin project you could follow here.
Someone has a sample of an app that popup a login page then call some service and popup a new login page if needed?
After logged via MobileServiceClient.LoginAsync, you would retrieve a JWT token issued by your mobile app backend and you could get it by accessing MobileServiceClient.CurrentUser.MobileServiceAuthenticationToken. And you could cache the token for reusing it. You could wrap the operations against your mobile app backend and catch the exception when the token is expired and manually call LoginAsync to ask the user for logging again or validate the token in your client side and re-login if the token is invalid before you send requests to your mobile app backend. For caching the token and validate the token, you could follow adrian hall's book about Caching Tokens. For wrapping the table operations, you could follow here.