Are they any framework or applications in asp.net to send/view messages for the users with in a site. It can be like email client application (like SharpWebMail), but it should not use SMTP server to send email. It should store messages in the database and the application should retrieve messages from the database
Basically want to setup the application in IIS and storing the messages in a database. I am looking in asp.net.
Related
My .NET web app presently uses Azure Windows server VM to receive and send SNMP email. My users send email to my web app, and my Windows server VM receives this email into its SNMP and then deposits it into a folder, which gets read by my backend .NET app.
I'm interested in switching to the new Azure web app model, but can't find anywhere how it would receive email.
My DNS provider uses my MX RECORD configuration to forward email from my users to the IP of my present VM server and then to its SNMP receive service, etc.
To receive email with a Web App in Azure App Service, you can setup a Web Job that can poll for new emails on a Schedule or Manual trigger, then perform a custom action necessary.
Another alternative is that you could create an Azure Logic App that is wired up to be notified of email messages. This can be done using the Outlook connectors (if you're using an Outlook email) or other connectors. Then the Logic App can be setup to make an API call to your app to trigger some sort of custom action to take place for emails received.
The configuration you have today on a full VM can not be implemented in Azure App Service Web Apps. The underlying managed VM that hosts the Web App isn't accessible and configurable in this way.
I am working on application whose details are as follows:
Its 3 tier architecture. Web Tier (ASP.Net MVC) -- Service Tier (ASP.Net WebApi 2) -- Database Tier(MS SQL 2014).
Application will also have native mobile apps as clients which will consume Service tier.
Service Tier (Web API) uses individual username/password in conjunction with OAuth for authentication and authorization.
User details are stored using ASP. Net Identity system. ASP. Net Identity database tables are in same database as that of application database.
There will be no direct calls from clients i.e. web or mobile apps to database and every request has to go via service layer.
Users of web client and mobile apps will be authenticated against asp.net identity database which is part of application database.
I have partially implemented above architecture however facing one challenge i.e. once user is authenticated, OAuth token will be issued from service layer which will be valid for one day. But how and where should I securely store this token in Web Client (ASP.Net MVC app) so that user needs to login only once in day and not for every single request that it makes.
One option I can think of is once user is authenticated and token is received in web client then store it in in-memory session storage and use it for further requests. However down side of this is, it will reduce scalability of application and will require sticky sessions in load balanced environment.
Is there any better way I can handle this situation? Also want to validate above architecture if its correct architecture?
I need to get Microsoft outlook details specially calendar & meetings of a person who invokes an ASP.Net web service via Windows authenticated page. Kindly assist how to connect Microsoft outlook calendar to ASP.Net Web Service.
Any given Outlook user's data is not guaranteed to be accessible from a web service or web application. If the user is using POP3 or IMAP account, their data will be stored locally on their PC and cannot be read without installing a custom client application to read their Outlook data and communicate back to your web server.
If they are using an Exchange Mailbox, then you can access that data from your web server via Exchange Web Services - but you'd need to authenticate with their password (or an AD token if you have that already in your web app).
From asp.net web application connecting the SSAS cube. Need to pass user credentials to the connection string. Web application is authenticated with windows identity. Web application users doesn't have access to SSAS, need to access SSAS with a service account credentials. SSAS service is not exposed in http.
Is there any way to pass the user credentials in ADOMD.NET connection string ?
I have implemented the Asp.NET web page and retrieved the data from cube to asp.net/MVC page. You need to create an application pool in IIS server first and connect the ssas to IIS server using windows account credentials. In ASP.NET use local host as the DATA SOURCE in connection string.
http://www.codeproject.com/Articles/6562/Cubes-MDX-Analysis-Services-and-ADOMD-in-C
http://www.codeproject.com/Articles/28290/Microsoft-Analysis-Services-Displaying-a-grid
I've got an ASP.NET (.NET 4.0) application that uses Windows Forms Authentication. This authenticates against Active Directory and works just fine.
This web app calls an ASP.NET Web Service(.NET 4.0) on the same server. Both the app and the service are running on IIS 6.
The web service calls a SQL Server 2005 database in the same domain using "Integrated Security=SSPI" as part of the connection string.
I want the web service and the database connection to use the credentials of the logged in user of the web app.
I've tried dozens of combination of settings from dozens of web sites, but nothing has worked. I'm on my second day and haven't gotten anywhere.
Is this even possible?
In my latest attempt, I added this code in the web app before calling the web service:
svc.Credentials = System.Net.CredentialCache.DefaultCredentials;
But inside the service, User.Identity.Name returns the value of the user who started the web server.
What you're trying to do is called "delegation". It means that the end-user is authenticated with the web server, and then the web server tries to use those credentials to gain access to the SQL Server. But the SQL Sever does not trust the web server, it only trusts the domain controller. So the request fails.
Besides not working, delegation has another disadvantage. Because each user would use different credentials, SQL connections would no longer be pooled. Each credential would have its own pool. That would be a major resource hog even at low user counts.
For more information, check out this MSDN article.
TL;DR: Give up on delegation and move to SQL auth.