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.
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.
There seems to be a lot of documentation lying around everywhere about how to use Google Cloud Platform and its fancy AutoML service. But I couldn't find anything that is solving my problem of trying to get a prediction from a trained model on AutoML via a local website. The website code is in this link: https://pastebin.com/xsfkYf6C
All I get in return from uploading an image and clicking "process" button on this site is:
{
"error": {
"code": 401,
"message": "Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.",
"status": "UNAUTHENTICATED"
}
}
I surely have made some mistakes somewhere, but I'm completely clueless as to how I would fix this or maybe because I'm just too dumb to figure it out yet. My research has yielded none to very little results. This article might be of some help to clear things up about AutoML Restful API: https://cloud.google.com/vision/automl/docs/reference/rest/v1beta1/projects.locations.models/predict
Appreciate any of your suggestions and code fixes.
Thanks so much and have a great day!
You need to pass your api key to REST API call like this:
https://automl.googleapis.com/v1beta1/projects/a...1/locations/us-central1/models/ICN...1:predict?key=API_KEY
To create an API key you need a Google Cloud account since it's only free up to a certain point and then you will get charged for.
Therefore you should secure this key and make sure it is not visible publicly(so don't put in your html source code, backend should handle this call).
More details here
The error could mean that you are using an API Key or the token you provided is wrong/malformed. I think that creating a token using Playground, ServerSide, Javascript, etc. will fail due to there are not OAuth2.0 scopes for AutoML, maybe because is still in beta release.
Keeping in mind that a token generated from gcloud it works, I can suggest generating programmatically a token impersonating a service account to generate the token, this example contains all the pieces of the puzzle. This means that your user could generate a service account token on behalf of your service
Points to consider when executing the code:
Enable the Identity and Access Management (IAM) API.
Update the code according to your own configuration, project and json file.
Use the generic scope: https://www.googleapis.com/auth/cloud-platform as the jwt_scope.
IMPORTANT: The python code it is using urllib and httplib, which means that it could be translated to a POST requests with some extra effort (to be used in your javascript)
Let us know if it works for your specific use case!
Background I have some experience implementing Oauth1a and Oauth2 as a client to connect to 'trusted' 3rd party services (twitter, facebook etc), but first time implementing the resource/authorization servers.
I have a basic but not strong understanding of different grant types, and how Oauth attempts to solve the authorization of a user/resource, while protecting user information (login information etc).
Scenario: we are creating a client-side application (reactJS) which must submit some basic information to a WordPress site. We control (are the authors of and will host) both react and WordPress on the same server.
We are using WP Rest API:
http://v2.wp-api.org/
And Oauth server plugin for wordpress
https://en-ca.wordpress.org/plugins/oauth2-provider/
Question
The further we get into implementation, the more I ask, what security to I gain at all by adding Oauth in this scenario?
For development and testing, the permissions callback on the POST to our REST endpoint is TRUE (open to any request), and now we are trying to secure it so only our application can submit information to WordPress.
The author of the Oauth server for WordpPress describes for this:
The access token used to preform a CRUD WP REST API action MUST has been acquired via the password grant type (user credentials).
Which requires embedding the following in the client:
client ID
client secret
wordpress user ID
wordpress user password
since:
The access token MUST be assigned to a user id with the correct
WordPress capabilities to preform the CRUD action.
Just to get back an access token.
Note: users do not log in via our react application. The application itself acts as one user in this case.
I must be missing something, exposing the WordPress user name and password seems less secure than skipping Oauth completely, leaving the POST endpoint open, and implementing some kind of submission abuse check, via submission rate, IP or other.
With Oauth2: Someone in control of the client can watch the XHR request and retrieve all information necessary to submit malicious data.
Without Oauth2: someone could use one of many discovery techniques to find our public endpoint and try to submit malicious data.
Things which I may be missing: should I be encrypting/hashing the password, secret, ID etc before embedding in the client?
Should I be separating out our authorization server from the resource server?
Have I missed the point, and Oauth is not a good candidate for this scenario?
Any insight or clarification greatly appreciated.
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 want to add "login with XYZ" capability to one of my web apps. I don't need any of the advanced stuff - just logging users in with one of their existing profiles so they don't have to remember yet another login credentials set.
After some research, I found HybridAuth and hello.js.
I know Javascript as well as PHP, but I have never implemented OAUTH 2 support before.
From what I can see, I could technically imagine implementing the identification and authentification both in Javascript or in PHP.
What would you recommend I choose, and why?
Since no comment or answer really answered my question, I'll answer with the additional reading I have been doing. I hope it will help if you arrived here via your research into the same question.
Having to use your "client secret" requires an OAUTH 2 client to have some server-side code (I don't want to have my "secret" in client-side JS, do i...). Hello.js solves this via a OAUTH Proxy.
Since I prefer to minimize my dependencies on third parties in production, I'd much rather use PHP in the first place.
Therefore, I will be implementing with hybridauth for now.
I had implement some of features like "login with Facebook", here is the common pattern,which is indicated by this picture.
What you have to do is firstly redirecting user to Facebook authentication server and when user get "code" from Facebook authentication server,you can get "access token" by passing "code" to Facebook authentication server(different url). Secondly, when you have "access token", you can now get user profile by Facebook API and then save to database or other thing.
So, the differences between hello.js and HybridAuth is that hell.js uses browser (Javascript) to do things after user redirect with "code", but HybridAuth do it on server side(PHP). But they do have the same pattern which is indicated by the picture.
I used both JS and PHP versions for FB.
Using server side library you can do your business without reising suspicions. For example collecting some public info to merge duplicate accounts, storing the profile image, login attempts. Other requests you might need for your business and user experience.