Need Guidence on Adding User Accounts and Payment System to Website - html

I have some business ideas I would like to try in the near future that would involve selling digital products like software or datasets. I know how to create a website as far as the HTML and CSS end, but I don't have experience with making web applications or user account systems. I would also be concerned with liability should someones account get hacked or payment information stolen.
I don't think what I need is anything too fancy. The customer needs to be able to create an account, purchase digital products, and give them access to those files on their account. I would also need the ability to remove, update, or add new files to their account after the fact.
Are there services that handle user accounts, hold files, and handle payments in one service? Maybe I could just create my own user account system and have someone else handle all payments? I could use some guidance here.

Shopify or Square if you don't want to do anything. You can also try Opencart, Megento, WooCommerce, Prestashop or Drupal Commerce.
EDIT FOR CLARIFICATION:
I did mean Square, not "Squarespace". Specifically https://squareup.com

Related

Synchronization across different systems

I have 2 systems let's call them i and j. Each have it's own database.
Each have a registration page, where a user is inserted in a user table.
What is the best way to synchronize both tables, where if any user registers at system i it will be also registered at system j.
Notes:
I cannot read from each other databases directly.
I can do small changes in the code if needed and it will not affect the system performance or natural behavior.
I can create API's for both systems if needed.
I can add any tables or fields if needed.
I can create any cron jobs unless it will affect the performance of the system or server.
I'm using cPanel.
Technologies:
MySQL
PHP
REST API's
The fact that you list cpanel as a technology shows you're working with an inflexible budget hosting vendor. So it's unlikely they'll cooperate in setting up background tasks (cron jobs) to merge your user tables behind the scenes. (cpanel isn't a technology: it's a system administration user interface provided by hosting vendors who don't trust their customers' skills.)
So. you should design and implement a REST API in the code of both your apps to perform user registration and authentication tasks. You didn't show us the details of your app, so it's hard to design it for you. Still it seems likely you'll have to implement these operations:
PUT user
DELETE user
GET user
POST user to validate a user's password, etc. (Don't use GET to pass secret information: GET request parameters go into server logs.)
PATCH to update details of a user.
If you get the API working, whenever you create/retrieve/update/delete user information in one app, you'll use the API to change it in the other.
Your best bet would be to create a third app just for user management, and have both your existing apps use it. That way you're sure to have one coherent source of truth about users. But you can do it just within two apps.

Send Serial Keys Automatically to Customers [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 12 months ago.
Improve this question
I have literally no coding skills. I know a little about bat, and html, and css. I hope someone can help with my question, as it seems no one has been willing to help me figure this out yet.
The Problem:
I manually send software keys these days to my own customers through secure email. But it has become tiresome, and some end users want the code right away, even at 4 am when I am sleeping.
The Question:
What do I have to do to code into my website to send the end user their serial key by email automatically? Have it automatically send the keys. All I would have to do is upload them securely somewhere for it to get it.
Maybe dropbox?
Any help would be helpful. Currently using wordpress. Would be willing to purchase any code or software if its already out there. Just having a hard time being able to locate it.
I've found my solution using Woo-Commerce and this solution:
https://www.licensemanager.at/
Basically, I'll be creating my own set of serials that have checksums in them (not using the built-in generators), and then load a few hundred in there ready to be sold and issued when people make a purchase.
Through the basic API of that plugin, I can then get the user to register online and so keep track roughly of when it's been used.
All free, just takes a while to set up, specifically the validating code in my program.
It's still fairly simple and primitive, but you can work around it's limitations.
I'd love to see if having customisable user level API permissions per API user, rather than a flat 'on/off' for each of the JSON API calls.
You could use a Wordpress for a fast website enviroment deploy, with the Woocommerce plugin, to allow people to buy your software, and the WooCommerce Software Add-on , to provide them the licences, once the payment is done.
WordPress
WordPress is open source software you can use to create a
website, blog, or app.
Wordpress Site
Wordpress WooCommerce Plugin
WooCommerce is a free eCommerce plugin that allows you to sell
anything, beautifully. Built to integrate seamlessly with WordPress,
WooCommerce is the world’s favorite eCommerce solution that gives both
store owners and developers complete control.
Wordpress Plugin Site
WooCommerce Software Add-on
The WooCommerce Software Add-on gives you the ability to manage
license keys and activations via your store.
Woocommerce Add.on Site
I'm not wordpress expert, I write custom php applications and I have an application with the functionality that you are asking. The application has password recovery page, product key retrieval page. And user gets Text Message and email.
Wordpress is written in php, so you can use the php mail(); function to send the email to the customer.
You can store the keys and other data in a database table. And create a page from where the users can fetch the required data automatically.
Lets say that a returning customer lost his key, he will come to the site, and will fill in his subscription email or other credentials, and the php script will fetch the key from database and send it to the user email using the mail function.
Refer : https://wordpress.org/plugins/wp-mail-smtp/
Hope this helps. Thank you.
You need to make your users sign up to your website. Like a registration form that allows users to register once, then upon registration, you assign a serial to their details and store them in a database. Then the script can send the serial to the user's email. PhP works pretty good for me.
After many more searches I did find the answer finally! I went to http://www.tipsandtricks-hq.com, went to products, and found "e-store". This plugin allows you to sell everything digital. And gives you the tools you need for a good price. I decided to buy the Affiliate and e-store plug-in.
Thanks for your help and time!

Storing and retrieving users shopping cart from database - Cart class - CodeIgniter

I haven't started the coding yet and really just want to get feedback on my ideas.
I would like to know how to store a users shopping cart contents in order to be able to retrieve them once they have returned to the website.
I'm confused with the idea of allowing users to create accounts, as I've read on this website that forcing people to create an account with you in order to put items in their shopping basket is bad practice. However, if I do give the ability to have an account, then I can create a table holding the accounts information, along with having a column for storing that users shopping cart content via the CI Cart class' function $this->cart->contents; (which I would then have to serialize before putting it in the table, right?).
I also wanted to know if it is possible to store the contents of a users shopping basket into a column as stated above, and then retrieve it back to display as the users shopping basket contents once they log back in.
Having an account would benefit in terms of having your shopping cart items available in different browsers, as they would be associated with the account and not your session.
But if I don't want to implement customers having accounts, do I just have to implement the Cart class, with no interaction with the database (and just setting the session variables in the config file to not expire, or expire in a year etc)? I don't understand why I would need the ci_sessions table in this case (any arguments for using it?)
Really confused because I've pondered over this for a long time, getting more confused as time goes by :(. Could someone please shed some light for me. Thanks
I think its always a good idea to get customers to create accounts because
Its a good way to stop span. Only allowing registered and logged in users to access the checkout stages is a lot better than just letting anyone get to it
Its also a good way to gather information about your customers that can be used for marketing
In regards to the cart you can save sessions to a database by making sure sess_use_database is set to true in the config files
$config['sess_use_database'] = TRUE;
That way you can add the customer previous items into the cart when they log back in.
But I agree with #dispake you've asked quite a lot of questions so its hard to give you a definitive answer

Tracking data access

Backstory
I work for a company that has an online site that allows user to text personal information for collection. We collect the data, and make it available online. Users can choose to share the data with other users.
Going Forward
At some point, this may become classified an FDA-governed medical tool. In anticipation, we'd like to have in place a logging system that shows each time someone accesses our users' data, whether it be the user themselves, another authorized user, or a support person.
Current Architecture
We are currently running Ruby/Rails, and using a MySQL database. The personal information is encrypted in the database.
Data Access for Support
Today, support personnel can access data one of three ways:
admin site The admin site is limited to whatever screens we develop. While we don't currently, we could easily add logging to keep an audit trail of who accessed which data using the admin tool.
sql client I use MySQLWorkbench to access production. However, when connected this way, all personal information (user name, cell number, etc), is encrypted.
Ruby Rails console - Finally, support can log into one of the production boxes and use the Ruby/Rails console from command line. Ruby will decrypt the data, so we can do some simple things such as
u=User.find_all_by_state('active')
and it will return the recordset of all users with state='active', and decrypt their personal information in the resultset.
Holy Grail
logging
easy access for support
I'd love to be have a way to allow easy support access (once authenticated) to the data, but would log everything that is accessed (read or updated). That way, if I'm checking out my buddy's ex-wife's data for example, it gets logged to a place where I can't get in and clean it the audit trail. (See Google firing Gmail employee for an example of employees breaching the data policies).
Anyone have ideas, thoughts, experiences, suggestions with this issue?
hey devguy. This was a issue for me a couple months back. We ended up centralizing our mysql queires so that we could start to track all information coming in and out. Unfortunately the class I wrote is in PHP but the idea behind it could make it very easy to start logging.
https://code.google.com/p/php-centralized-mysql-controller/
Try stored procedures. Make all code use the stored procedures for CRUD activities. This defines an API that your developers can use while business rules are global enforced (don't return entire SSN values, but only last 4 digits, etc).
This serves as the basis for an external API as well.
If you want logging/auditing, you put it in the procedure.
This protects you from everyone except the DBAs.

Web application Development - Subdomain

I'm currently at the very early design stage of building a web app that will be used by companies. Each company will have many departments and each department many staff. Each department will manage its own application with staff logging onto the application.
There is the possibility that staff across different organisations will have the same staff id. For that reason, I'm thinking of going with subdomains. Each company will have its own subdomain. I've googled a bit about using subdomains and have seen a number of positives, however not too many negatives except for the SEO implications (which do not interest me really.. this app will require direct contact with each organisation.. it's very specialised)
Can anybody think of any other disadvantages to going with subdomains? Can anyone think of a better way of doing things?
Regards,
Fiona
Your login information will presumably be in a database table somewhere. You will either need separate databases for each company and will need to identify which database to use. Or you will have all users in one table, with some sort of company id - and you will need to determine which company id to add to your login query.
You can make either of these determinations based on subdomain, or on a company-specific login page, or directory, or you can ask them to pick which company they want to log in to (which would be pretty ugly).
Subdomains should work fine. You'll have to do DNS setup every time you add a company, or work out some apache magic. You may need SSL certificates for each subdomain (I think - I'm not well versed on those). Other than that, I don't see any big disadvantages or advantages as far as code or architecture go. Marketing may have a stronger case for one over the other.
You'll still want to use other methods of making sure that users don't have access to other companies' data, especially if other subdomains are guessable.
We also have a multiple-company application, but decided to make all logins unique. This makes it a little easier for us to identify users uniquely at the expense of occasionally having to explain why some username is not available even though that user's company isn't using it.
using sub domains is a good idea, the only concern i have is regarding the authentication of the users. I am a .net guy so i am bringing up this query, i am not sure if you are using asp.net for your development. In case you are using asp.net for developing this website and you are using the asp.net membership, profiles and roles for authentication and authorization, you would end up having security problems. Because a user after logging into http://abc.site.com would have access to the site http://xyz.site.com also. This is the default way the asp.net membership thing works. So you would need to keep this in mind.
Rest i think the sub domain philosophy is good enough.
Subdomains might work just fine with asp.net membership. Because the was the tables are created for the membership provider there is a aspnet_applications table which has fields for te application name and description. In the aspnet_memberhip table, each user has a field for applicationID. If the application name is the subdomain then you could possibly limit which user can gain access to which application. XYZ subdomian would be one application with it's own ID, and ABC application would be another one.
Interesting domain problem. Good luck and share your results after it's creation.