I am developing a system like Online Exchange(olx). This system require a verification from the user that the number entered by the user in ad is correct or not. for that purpose I want my system to send a message to the number given by the user with a verification code.
How can I implement this system in asp.net?
You can't send an SMS on your own.
Rather, find a service provider in your country and contact them. Providers offer paid services that are usually exposed as web services.
Technically, your application calls a provider service over http[s] and you pass a phone number and the message body. There are usually multiple payment methods, for example you can pay for a message pack or your clients can pay on their own by first sending their message to a fixed number.
Related
I am developing a web application that uses Microsoft accounts to sign in. How can I safely and reliably grant external users access to this application by email address without requiring that I train users on Azure administration or have to implement some approval mechanism via API?
I believe that it is dangerous to use the ClaimsPrincipal.Identity.Name, which returns an email address. It uses the "preferred_username" claim behind the scenes, which along with the "email" claim are documented to not be a safe and reliable way to identify a user, so I assume that's user configurable and thus can be spoofed by a creative user.
It seems like if the user knows the email address or account name that they use to sign into their Microsoft account, that should be enough to authorize that user to access the application without requiring that they go through an additional step of verifying an email which I trust they use to sign in, but I can't seem to find a way to do this.
Here is the process of creating and granting the external users access to the application:
Please go this document for more details:https://learn.microsoft.com/en-us/graph/api/invitation-post?view=graph-rest-1.0&tabs=http
Hope this helps.
I've been using Firebase for a while and have successfully used it to verify phone numbers in past projects.
Now I'm trying to implement it completely on the backend because at my current project the end user (phone app) doesn't have internet access but the backend (the user is connected to) has.
My plan was:
The user is entering their phone number and sending it to my backend
The backend should send the phone number to firebase and send the client an SMS with the verification code
The client enters the verification code and sends it to my backend to verify
I wasn't able to find this and I'm not sure if it is supported. Any hints?
Firebase Auth does not support this. The APIs are driven from the client app, which is always where credentials are established.
If you need a way to verify a phone number only from a backend, you'll need to use another service. I'm sure you can find some using a web search.
you can use it as front-end third party login service like sign with google etc... with use of link
I work for a subscription fulfillment company, where we handle the subscriptions to various magazines (renewals, invoices primarily). So we email out to the subscribers when they purchase a magazine, that we are charging them for their monthly/annually renewal or they sent us a question about their subscription and we are answering them.
As of right now, we are creating email addresses on our domain for each of our clients (the publishers), but the publishers want us to send out the emails with their domain name as the from (not ours).
I know this can be done because we purchased email blasting software and it does it without a problem (the clients put in SPF records so that it won't be marked as SPAM). The problem is that when our .Net (specifically VB.Net) application goes to send out emails with a From from a different domain, I get back that the user we authenticated to our internal SMTP server with isn't authorized to send out on behalf of the From.
I got a partial idea from Send SMTP with From address of another domain that maybe I could ask the publishers to issue us credentials to their SMTP server and have the .Net code try using their server and credentials to send out the email, but I would prefer not to go that route.
On the same note, our people use Outlook 2010 to answer most of the customer service emails, so it would be good if the solution for the .Net could also work for Outlook. If it doesn't, it doesn't, but at least the .Net one is a step in the right direction.
Now, I am a .Net developer, not an SMTP administrator (but I'm the closest to it that we have). So any instructions need to be detailed, please assume that I am ignorant in this area, so if you say go run program such and such, please state where program such and such is.
I'm designing a web-based app that will have its own authorization system (via Codeigniter-based Ion Auth) and will also be logging into a service in the background via API calls (Adobe Connect webinar services). When the user creates their account on the base system, it will simultaneously create an account on the Adobe Connect system, using the user name and password they enter. Easy enough to do.
The problem comes when making API calls to their account. During initial sign-up, the Ion Auth code translates the user's password into a salted hash value but this won't work for the API calls, which require their in-the-clear password for authorization. It wouldn't be an issue except that the user will also need to log into the Adobe Connect system directly for some functions.
My first thought is to create a field in the user's profile that stores their password in encrypted form, then decrypt it before passing to Adobe Connect. Does anyone have a better method to suggest?
Thanks in advance,
Mark
We are running a Saas ASP.NET 3.5 Web application using Forms authentication on a IIS 7.5 public server with protected content for thousands of users. We also have some subapplications running ASP.NET MVC 2.
Usernames and passwords are stored in our database and every user has roles and groups attached, with privileges and access rights defined.
Now we have been asked to also facilitate for simple SSO login via Active Directory so that users do not have to enter username and passwords twice to login. These users will originate from different networks and domains.
No user "sync" should take place from our servers to LDAP serves. We are not sure that any communication with LDAP is needed since all users will be created in our system and maintained there. Forms authentication will be used for most of our users.
From here on we are unsure which is the best path to choose. For our scenario what would be the "best practice" way to proceed?
The simple answer is SAML. It is considered the "best practice" and many large SAAS providers support it.
SAML protocol defines the single sign on flow between multiple systems. It establishes trust between systems using certificates. Your application accepts an assertion containing attributes (user id, name, email address, etc.) from other systems. Your app will map the user into your user store.
In .NET world there are several options. You can find a library that implements SAML (ComponentSpace has one) and hook it into ASP.NET authentication. You can create your own using Windows Identify Framework (WIF). Here's the boatload of WIF videos http://www.cloudidentity.com/blog/2010/06/23/ALL-WILL-BE-REVEALED-7-HOURS-RECORDINGS-FROM-THE-WIF-WORKSHOPS/. You can try IdentityServer http://thinktecture.github.io/
Depending on how secure your app must be, you can opt for a simple option of passing user id from trusted networks using a simplified method. I've seen apps that allow user id to be sent via URL parameter or form field. Of course, this is horribly insecure, and you are taking on more risk, because the trust between two networks is not cryptographically enforced. You can mitigate it somewhat by checking referrer string or IP address (if you can isolate IP range of a corporate network for example). But you are still open to spoofing because any user can impersonate others by simply replacing user id within HTTP request.
It probably doesn't answer your question fully, but hopefully points you in the right direction.
I recommend looking into ADFS 2.0 it is very powerful in terms of claims mapping and works with AD: http://msdn.microsoft.com/en-us/magazine/ee335705.aspx
What you would make is a token consuming portion of your app that would receive and parse the final claims returned to your web server after the authentication loop.