is possible to use the AWS SNS in the client, with Javascript?? I am creating a website that has a booking form , and I would like to send an email notification as soon as the user presses the submit button, for this I thought of using the Simple Notification Service, however I 'm not finding the documentation using with the client side. Would anyone tell me if it is possible ? I've searched on google and did not get a satisfactory answer.
Yes, you can use SNS from the client, the SNS JavaScript SDK explains how you can do that.
However, as John R said that's the wrong tool for the job. You really want to be using SES to send email.
Regardless of which one you use the biggest obstacle is not the code, it is the authentication from the client side, look here to get started.
For whatever its worth, I do not think that's your best approach. Unless your users can spot milli second differences I would just do it on the server side. I do not know what server side language you are using, but any of the ones that have an AWS SDK make this trivially easy to do.
Note though that AWS does not allow you to send production emails before you are verified. I would suggest you read through the AWS documentation for SES first. They are pretty comprehensive.
The Amazon Simple Notification Service can send a notification to subscribers in several ways:
Email (but with an 'unsubscribe' footer)
SMS
Mobile push
Push to an Amazon Simple Queue Service (SQS) queue
Messages are sent to an SNS Topic. Any subscribers to the topic then receive a copy of the notification. All subscriptions to a Topic must be confirmed.
Therefore, I would not recommend using SNS as a method of sending an email to your users. Instead, use the Amazon Simple Email Service (SES), which is designed to improve deliverability for outbound email.
There is a JavaScript SDK that can connect to SES.
Related
I am trying to integrate docusign with a React Native app I am building. My desired workflow is to have the user launch a remote signing envelope based on a template.
From the Node JS examples, eg009 seems to be the end result I am after. However, I am wanting to complete this with Axios/Fetch and Javascript.
My intended flow is to have the user enter in their name and email, and their spouses name and email. From there they press a submit button which sends the API call, and that is the extent of what the app does.
I am wanting the API call to then start the template flow, sending a document to sign via email to both that were entered into the app. I want the users to authorize themselves from the email, not the app. After both parties have signed, I want it sent to a third static email.
I do not want the users to have to authorize inside the app or be redirected anywhere. It seems a JWT would be best.
Does this seem possible? How would you suggest going about this?
I appreciate the help!
Looks like the JWT grant flow is the right fit for you here. Please see this article for more details: https://developers.docusign.com/platform/auth
There's no good solution for running DocuSign API calls from client as a result of CORS limitations.
Larry has some blog posts on this topic - https://www.docusign.com/blog/dsdev-building-single-page-applications-with-docusign-and-cors-part-2
You could use something like AWS lambda which is not a server per-se, but gives you server capabilities without the hassle of a server.
Check also the latest blog by Larry on this topic which superficially covers using React for single-page apps.
What is the difference between using Google OAuth and signing in users at the frontend of the application, and signing in users at the backend side of the application?
Example: Signing in users and getting the ID and a auth object in React or letting Node/Express handle everything, the prosess, redirecting and store it in a database.
Is there any advantages for one or the other methods, which are most common and are there any "rules"?
What is the difference between using Google OAuth and signing in users
at the frontend of the application, and signing in users at the
backend side of the application?
So to clarify to everyone reading this, signing in users at the backend side of the application is another way of saying OAuth for servers and signing in users at the frontend of the application is OAuth for JavaScript browser applications such as React.
Signing in users via OAuth for servers and browsers results in a 'token' that a server/browser can use to make requests on behalf of the user. We are asking the user to provide us access to their information via an outside service provider such as an email address, identification of some sort and it will be inside that token as well as some possible permissions that allow us to take actions on behalf of that user.
Is there any advantages for one or the other methods, which are most
common and are there any "rules"?
Server-side OAuth is usually used when we have an app that needs to access user data when they are not logged in. So if you are attempting to build an application that needs to access the users email every ten minutes and possibly delete emails on the users' behalf, you would want to be able to access their email account every 10 minutes regardless of whether they are logged into our application. So for this use case we want to make use of Oauth for server.
Otherwise, if we are not trying to do anything on behalf of the user except sign them into our app, then we can just go with OAuth for browser.
Those two things are very different. Without knowing the specifics of what you're trying to accomplish, you should know as a general rule that front-end-only authentication and authorization leaves you extremely vulnerable.
If someone knows JavaScript well, or is using editing plugins, or any of a million different things, they can bypass much front-end authorization. Or they could just watch to see what calls your app makes to the back end, then simulate those calls from something like Postman, bypassing your web front end entirely.
If you're not securing your backend, you're not secure. Typically systems do both.
It is just a different ways of registering users to our website.
Signing in users at the frontend using OAuth can be very handy as it enables our users to not go through our boring forms in our website. Using OAuth is just one click away from registering users in our website. Beneficial to both the clients and developer.We are provided with the general information about clients by the provider(google,facebook) just clicking on one button.
Signing in users at the backend side is the traditional way of registering our clients. Here we force our client to fill the forms in our website(which may be painfull if it is a long form) and all the filled data is stored in our database.
So they are both different ways to register clients to our websites. Both are used very often. It depends on usecase and needs. Oauth can be used if you want to attract more clients by registering them just by one click.
I'm working on an Android app in react-native and the app communicates with an API I'm working on for the app. The API is built with Laravel and Laravel Passport.
I know that Android apps can be decompiled so any secret keys stored within the app could be easily found. This is the reason for my current approach.
You can only gain an access code during registration. The application uses anonymous accounts so if you lose the access token, it's too bad. The app makes an API request to /api/register which creates the account and returns an access token. The app would store the token and use it to make further API requests.
The problem is that the registration route does not use any client secrets or access tokens. It is very easy to automate requests to the route and create an army of bots. I could potentially limit the amount of requests like a lot of API providers do but that wouldn't stop the issue.
I've heard about payload hashing but this usually requires a salt that is in both the app and api. Again, this is not secure and couldn't someone just hash it themselves if they know the salt to spam requests? Maybe I'm misunderstanding how payload hashes work.
Hopefully someone can assist.
You'll probably want to use something to detect the user agent hitting the route. This package has a lot of useful features:jenssegers/agent. For example, it offers crawler detection:
$agent->isRobot();
Depending on your hosting provider, you may have access to tools that automatically blacklists ip addresses after X number of requests per minute (or other metrics). I know AWS offers this service.
Another option is antonioribeiro/firewall. Track users based on ip or geography and redirect/block accordingly.
I'm at this junction at the moment and the route I'm taking is one where the user is challenged to solve a simple puzzle:
registration process on app/web picks up a challenge from my registration server
the challenge is shown to the user with the input fields: email/username, password and the answer input for the challenge
it all gets sent to the registration server and if the answer is incorrect, the registration is denied
This "are you human" challenge is what will stop bot-registration so it needs to be a little smarter than the one coding the bots, so a selection of various challenges on the server would be nice.
I'm thinking of "select the n-th value from the dropdown", "select the first/last option", "write the color 'blue'" or "what whole number is between 3 and 5", and so on, for which variables can easily be generated by the server, the challenge and answer input can easily be created by the registration script, and it's easy and not very time consuming for the user to solve.
Another option I'll explore is to throttle requests by IP, combined with black-and white-listing those.
Indeed it is an awesome day to everyone but not for me because I've been handling this battle cry for more than 13 days now and cant get it done. I have searched across the web but cant find the solution that can get my butt out of this mess. And yes stackoverflow is always my last resort when things get worse.
Can anyone suggest what is the best way(or even alternative) in sending email using js or jquery ?. Perhaps a simple snippet would do. Thanks!
You cannot send an email within the client browser. If your website is running on your own webserver, you can send a request from within the browser to your server that sends an email. If you're running a node.js server, there are many email apis.
For example, my business is a Mailjet customer, and so I can use the node-mailjet api on my server-side. Also there's https://nodemailer.com/ and similar npm packages.
Sending email only using javascript on client-side is not possible. By that you would give full control to user what and where he sends email - cool spam solution..
I wouldn't recommend to expose service from server that send email to client-side from server-side with full settings of message that will be sent. You don't want to allow spamming.
Only good approach is to predefine email on server and then when triggering action occurs resolve dynamic values in email on server and send email from server. Still you have to ensure user cant spam with some security policy.
So how to get out of this ? Implement service on server that will send emails for you (called with AJAX), lets say by code name and parameters. On server-side, choose template by code-name and resolve it by parameters passed with server request. Implement you security policy so you can be sure user cant spam (for example when user can choose to which email address will be message sent). Then pass it all to SMTP.
I'm building client server REST application.
Client side is based on Angular while server is PHP (not that it matters much anyhow).
What I am wondering if there are any best practices, good examples of captcha implementation in this case? Captcha would be used for user registration etc.
I'm not limited to any specific libraries, only requirement is that there cannot be any calls to 3rd party servers on client side (js libraries hosted on 3rd party servers or req api key etc).
thanks
When google captcha approves one user, it provides you a token.
So imagine this scenario. A User is about to save, and uses the captcha, the captcha does its business and gives you a token, it is all that matters.
If you want to see a "tentative" flow of requests for this.
The User should pass the captcha before registering and retrieve the token that it provides in the front end.
User clicks save, you receive the captcha token in the backend as form data. You validate the token with Google via an API. If Google verifies the token as valid, you can save the user or reject if Google returns an error.
The frontend listens for success or error and what kind of error. IF error is captcha, force a retry, get a new token.
Backend receives a new token in form data and repeats step 2.
You can have a look on google-recaptcha. Its angular implementation is here
vcRecaptcha
Google's new-ish reCaptcha is pretty slick. They have several easy to understand examples and usage scenarios.
https://www.google.com/recaptcha/intro/index.html
Edit: To address your specific question of how to implement this in a RESTful application, I'd make two files. One would be a public-facing file like index.php and the other would be a back-end file that would hold the private information.
I could copy/paste my previously-written how-to here, or I could just link you to the article I wrote 2 months ago.