Can I use https://stripe.com/docs/stripe.js a full alternative of the server side code, for example, gem stripe in Ruby? I figure I can do something in stripe.js but it will only get me so far. In particular, I can't create and manage Subscriptions, Invoice, InvoiceItems in stripe.js, can I?
Stripe.js will only permit you a secure but easy way of gathering payment information from your users.
You will still need some server-side or backend code to process the information and finalize the payment, or to manage anything else like subscriptions or invoice items with an API library for the programming language of your choice.
Related
I have a JavaScript SPA which consumes a backend REST API built with Django (Django Rest Framework). It's a small academic project which is likely to attract only a few hundred users on a regular basis. Our initial design assumed that users might wish to save data, but recent consultation with potential clients has made us question whether we need to incorporate this feature. So this would completely remove any need for POST requests to the backend API, leaving only GETs. These GETs (via axios) contain only path parameters, no query params, and return small JSON payloads, used to render SVG components in the application (this data is read-only, static data, already stored in the backend db).
The assumed need to cater for user uploads led us to also add user login/logout and account management features. We even started to look at integrating Auth0. But if we remove user upload entirely do we even need to secure our API endpoints in this way?
From what's given in the OP, answer is, No, you do not need authentication.
Irrespective of the HTTP verb used, just ask yourself, whatever functionality you are exposing through your REST apis, at least, do you care to find out who did what using your APIs? if not you don't need Authentication
Basically,
Do you want to restrict access to any APIs?
Do you want to tie an action to any persona?
Do you want to audit, (who did what when)?
If answer to all these 3 is no, you do not need authentication.
I have a static JavaScript-only data visualisation. I want to collect the user's name and email before showing them the visualisation.
I have written a popup form to collect this info. But where can I store it? Do I have to add a whole back-end service and database just to store two variables?
I just need to POST two text strings, safely and reliably, from client-side JavaScript, and download the data as needed. Surely someone must offer a service that allows this? I would happily pay to avoid writing my own backend.
(I've looked at embedding a Mailchimp form, but it's too painful to style it in the way I need - I'd prefer to use my own front-end code.)
Have you looked at Campaign monitor ?
You can create a List that has the name + email then you can push this data to that list using AJAX:
https://www.campaignmonitor.com/appstore/ajax-subscription-form/
AWS Mobile Hub (DynamoDB, Lambda, API Gateway, Cognito)
-Integrated console that helps you create, build, test, and monitor your mobile apps that leverage AWS services
Parse server
-Open source server released by Parse/Facebook to replicate functionality of Parse
remoteStorage
-Everything in one place – your place. Use a storage account with a provider you trust, or set up your own storage server. Move house whenever you want. It's your data.
Is it possible to create PayPal subscriptions using only a client side javascript (and Firebase if needed)?
I'm a bit confused with PayPal; there are so many frameworks/options to do same thing that I don't know where to look exactly.
https://developer.paypal.com/demo/checkout/#/pattern/client
This seems similar what I'm looking for except it's only for payments, and I need subscriptions.
Just an update on this ticket. Paypal do now have a javascript client-side API that works very well. Here is the link: https://developer.paypal.com/docs/integration/direct/express-checkout/integration-jsv4/
You can use PayPal WPS Subscription Buttons
https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/Appx_websitestandard_htmlvariables/#recurring-payment-variables
This is a button integration so you can use JS and HTML to create a plan and redirect buyers to paypal.com. You can specify your subscription terms and PayPal will take care of making recurring payments. You can also maintain inventory, profile & loss tracking.
For any API integration its highly risky to use client side JS.
I am at the stage where I am thinking of integrating a social login method into my site. Of course my first one will be the facebook login before moving onwards.
Basically my question is : Which language is best for this type of OAuth connection, and which is going to let me do everything I want?
This will encompass all OAuth connections in general eventually, but specifically Facebook for now.
From what I have read of the documentation, the JavaScript SDK allows you to login, and connect to the open graph API - which in turn will allow me to post / upload etc etc. This is also available in PHP.
From experience which is the more durable route to go?
PHP or JAVASCRIPT
The best and recommend way to authorize users is the JavaScript SDK (FB.login). No redirect needed (better usability), very easy to handle, no PHP needed (the new PHP SDK needs PHP 5.4+). Use PHP only for stuff that involves usage of the App Secret or Extended Access Tokens. And for cron jobs, obviously. You can even just forget about the PHP SDK and use your own CURL calls.
Btw, security is no problem, you should just activate "appsecret_proof" in the App Settings.
More information about appsecret_proof:
https://developers.facebook.com/docs/graph-api/securing-requests
http://www.devils-heaven.com/facebook-php-sdk-4-0-tutorial/
One more reason (and one of the most important ones) is the possibility to refresh Access Tokens (=User Sessions) easily without page refresh by using FB.getLoginStatus.
And another reason is that you need to upgrade to new PHP SDK versions on your own. The JavaScript SDK does not need any upgrades, in the lase few years you only had to change one or two parameters in some cases, the SDK gets downloaded from the Facebook servers.
Also, if you add Social Plugins, you need the JavaScript SDK anyway.
TL;DR PHP/both
I'd really recommend PHP. You'll want to store the login in database. If you do it via JS, you'll need to make an Ajax call to the server, which is not really that secure.
Having said that, they are targeted for different uses. JS is for frontend more, while PHP is for backend (db storage, checks, actual site login, etc). Using JS will let you generate the buttons on the fly, while using PHP you'll need to do some more coding.
Somehting else, the php library will get updated from time to time and you'll need to keep up after testing. JS also, but it's easier, since the code usually works.
If you only want one, use PHP. You can control what the code does and JS will not break your site since it's written by you. However, I'd recommend using both since you will probably want more than just simple login
Edit:
As facebook states, use PHP SDK: Usually this means you're developing with PHP for a Facebook Canvas app, building your own website, or adding server-side functionality to an app that already uses the Facebook SDK for JavaScript.
https://developers.facebook.com/docs/reference/php/4.0.0
The best route would be to use both, together. Some users might have javascript disabled or you might do something within your javascript code that will not work on some browsers. So as a fallback method you can use php api.
Going with only php would be solid and will work regardless of what the users client is, but you can make the user experience better with javascript.
Still, in most cases you'll end up having to use both.
I have just spent the afternoon playing with the JavaScript SDK for facebook and I have to admit I think this is going to be the best option for what I need.
If anyone else is reading this, it may not be perfect for you - but with the way my application has been built I think it is a perfect fit. Here is why :
My standard login system uses JavaScript to grab my form data, then validate, which then passes the validated data via AJAX to a PHP validation script. Which in turn returns a JSON response to the original AJAX call. If my call comes back with "ok" : true then we are good to go basically.
The way the facebook JavaScript SDK works is almost a perfect little jigsaw puzzle to bolt onto the system I am using. All I require is a little bit of profile data, to then keep a record of this user on my system. THIS is provided by facebook, then validated by myself.
However, other social network logins may not be as nice and simple to use as the facebook API, so I could end up changing my mind on the overall system. For now just using facebook, I think the JavaScript SDK is absolutely spot on, as it just gets the information for you to run through your own validation on site. As I said this is a perfect fit for my system however it may not be for yours.
I have a web tool developed, which uses node.js and socket.io. it's a one page website and uses node.js for getting data from social media website and display on the same page. I would like to add a site specific login system for the website but don't want to use 'Express' or 'Passport' as it adds lots of overload to the website while it is not needed.
I am newbie with node.js and would like to know if I need to have a login system made with node.js to maintain session of the logged in user?
Note: I need to maintain session to log user data such as login time, search query and may be heatmap.
Thanks in advance. If needed I can explain specific part of the question in detail.
Using something like Express or Passport (or at least some of connect's middleware) will definitely be easier in the long run (if your app grows), but if you want to go the 'manual' route, here are some starting points:
Cookie Parser: You won't want to send the auth details with every request as a parameter, so you'll want to put the session details in a cookie. You can set cookies manually using headers, or with a node module that wraps the API neatly.
Session Storage: You can put all the "login time, queries and heatmap data" in cookies, but it would be neater to just send a session id in the cookie in each request and save the other data server-side in a database. Options are mongoose, redis, etc.
Since reading the source is very educational, go read connect's cookieParser and cookieSession. It's not a lot of code and the API docs include the actual source, so it's very easy to learn from. Enjoy! :)
From how you are phrasing this question, I believe the overhead from using Express modules (Passport or similar) is the least of your worries ;-)
First you need to figure out which mechanisms you want to use.
For authentication, will you use a username/password combo, or will you be using a third party service like Google, Facebook, Twitter etc ("OAuth" like)? Unless you use some third party service, you also need to handle registration (and possibly verification of email address etc). Even for username/password combos, will you roll your own or use the browser based "basic-auth" mechanisms?
After authenticating you need a session mechanism to store some session token to recognize (and verify server side) that you have been authenticated. They are typically stored in browser cookies, which can easily be persisted for as long as you need, and are verified with each relevant request with tokens in a database on the server side.
And finally, you need a logout mechanism and a "I forgot my password" procedure (which may very well be manual initially...).
If all this is fairly new to you, I suggest trying to use something ready-made first (you mention Passport yourself), and then when you've mastered the basics, feel free to replace it with your own. The "upside" of using Passport or Everyauth is that they cover a lot more options that you realistically will be able to write yourself, so once you've adapted your system to use one of those, adding Facebook logins and similar will be a lot easier (somebody already figured out most of the stuff for your).
To be honest, most of the modules that handle such things in the Node ecosystem are fairly thin wrappers on top of whatever solution you decide to use, so the overhead will most likely not be substantial and you will most likely need a good understanding of the issues anyway to use them. At the other end of the spectrum are ready-made-systems like Drupal etc where everything just works, but then you're somewhat boxed in as far as making your own system.
There are use-cases where rolling your own from scratch is absolutely necessary, but there's nothing stopping your from doing this later when/if necessary (and after you've mastered the basics with the help of code that others wrote).
Best of luck!