After weeks of back and forth in Cursor, trying to resolve the linting errors (due to Vercel’s strict deployment policies), I was finally able to solve them after upgrading to Claude 3.7.

If you want the full source code, you can check it out my repo: https://github.com/anantgarg/chatbot-builder

Here is the final look of the Chatbot Builder-

Try it out yourself at:

https://chatbot-builder-test.vercel.app

Deploy your own Chatbot Builder

To publish your app to Vercel, here are a few simple steps:

1. First and foremost, fork my chatbot builder repository (and don’t forget to give it a star!)

2. Then signup and login to Vercel

3. Add a new project and select the forked repo from Import Git Repository

4. Hit Deploy (don’t update the environment variables as yet)

5. You’ll get an error. That’s okay. Click on the Goto Project button.

6. In your project, head to Storage and click on the Create Database button. Now select Neon (Serverless Postgres) from the options. Choose the free option and create the database.

7. Now head to Settings and click on Environment Variables from the side bar. Add `JWT_SECRET` key. Verify that `DATABASE_URL` key is already present (would have been auto created if the database was successfully created)

   

8. You should see a toast asking you to redeploy. Click on the Redeploy button and follow the onscreen instructions.

9. Once successful, click on the Visit button to view your Chatbot builder

   

Test your Chatbot Builder

1. Head to the deployed URL and sign up for an account

2. Go to Settings tab and input your OpenAI key. Click on Test API Key to test if the key has been correctly added.

3. Then head to Bots tab and create a new bot

   

4. Then head to Files tab and upload relevant files and attach them to the newly created bot

   

5. Then signup for an account at CometChat and head to Manage > Users tab and create a new user.

   

6. Then head back to your Chatbot Builder and next to the bot you created, click on Integrations and then Configure Integrations and select Enable CometChat Integration. Add these credentials from your CometChat Dashboard > Application > Credentials page.

   

7. Hit Save and you should get a web hook URL

   

8. Now head to CometChat Dashboard > AI Chatbot > Non-AI Bots and create a new bot. In the UID, use the same UID as the user you had created and for the URL, use the Webhook URL generated from the Chatbot Builder. And finally hit Save.

9. Now head to Manage > Groups and select Edit for Hiking Group and then Add Members. Add the new bot you just created.

10. Finally, run the sample CometChat React app by following the onscreen instructions

    

11. If everything went as per plan, you should be able to head to the Hiking Group chat and ask any question and get a response from the newly created bot!

    

Getting Started from Where We Left Off

Let's jump right in from where we concluded our last session. Previously, I had enabled ngrok, but I hadn't set up the service to accept data yet. Today, I'm addressing that by creating a basic API endpoint. I have given an example of the type of content coming in from CometChat, and the endpoint has now been created. Let’s send a message and see what happens.

Upon sending a message, I noticed it was redirected to login. To bypass this during the demo, I’ve decided not to implement additional authentication right now. In the future, we can certainly add more security layers. For now, I've integrated the bot ID into the URL, allowing us to determine which bot is making the call. I've also included this information on the configuration page.

Configuring the URL and Testing the Response

With the bot ID, I've updated the URL in the CometChat dashboard for the bot. After testing, I found out it was still redirecting. Once fixed, we tried again, and this time the response returned a status OK. Then, I modified the setup to send out a response by integrating relevant code from CometChat's API documentation. Now, upon completion, there should be a response from the system—although initially, the response looped back to itself, sending the same message repeatedly. This was due to an incorrect URL end-point, which has since been corrected.

The Breakthrough with Gym Bot

After rectifying the endpoint, we successfully received a response from Gym bot. Moving forward, I decided to enhance echo bot further by fetching responses from OpenAI and forwarding these to the user. I've associated a workout file with Gym bot, configured all the settings with CometChat, and thoroughly tested this several times.

Running the test on a local system takes a bit longer than it would on a server, but ultimately, I received the desired response, which was extracted from the file. The next step in this developmental journey will be to remove markdown syntax and replace it with standard content to simplify responses.

What’s Next?

There you have it! We've built the whole flow with CometChat. In future episodes, I'll be adding other integrations, such as with Facebook Messenger and WhatsApp. Stay tuned for more advancements.

Thank you for following along.

Bye!

Beginning with Integrations

To kick things off, I went ahead and prompted the system to add an integrations page for each bot. However, despite following the setup instructions, I noticed it wasn't taking effect as expected. After some trial and error, including messaging the same error message again, it still didn't work. When I checked the file, it appeared that the relevant code had been added, yet it wasn't reflecting in the final product. After a bit of investigation, I realized I had added it to the wrong file. Finally, after correcting the location, the integrations page appeared as intended.

Integrating with CometChat

Next was the exciting part: moving on to CometChat. I started by downloading CometChat's React v5 UI Kit and executed a series of commands, one at a time. Progressing to the dashboard, I navigated to the 'Bots' section to ensure I had created a gym bot. This was crucial because I was using a product called "ngrok." Ngrok is quite handy for turning localhost into an accessible web interface.

Once set up, I confirmed the gym bot's presence in the group's list. Sending a message to the group should trigger a receipt of that message on the other end, and indeed, upon checking ngrok, the message was successfully received.

Looking Ahead

In our next session, I'll be working on connecting all the dots to complete this communication flow. When a message comes in, the plan is to process it through OpenAI, enabling us to send an appropriate response back. This will wrap up the integration process neatly. Following this, I plan to focus on expanding the range of integrations even further.

That’s all for now. Thank you for reading, and I hope you found this insight into the integration process useful.

Until next time,

Anant

Thanks for joining me. Today, I'm diving deeper into the exciting world of multi-tenancy as I continue to refine my chatbot platform.

Debugging the Files Tab

The journey begins where I left off last time - the files tab wasn't yet fully equipped for multi-tenancy. Previously, accessing the files tab fetched and displayed a list of files directly from OpenAI, which wasn't ideal. Now, I've revamped the code to pull these files from the database instead. However, after making this change, I encountered an error message: "failed to upload file." To troubleshoot, I looked into the issue and found that while the file was getting uploaded to OpenAI, it wasn't being added to my database. It turned out that the user ID being fetched wasn't correct. After checking and rectifying this problem, things seemed to work smoothly. A quick look at the files table confirmed - an entry had been added.

Next, I logged out and tried the process with a different user. I noticed the same file was showing up. To solve this, I uploaded a second file. The upload went through, but it became clear the files list was incorrect - it was displaying files like "mega guide" and "golden rules" across different users. I'd instructed the system to show files specifically for the logged-in user, prompting another round of code revisions. After these adjustments, each user could now see their respective files: user one saw "mega guide," and another user saw "golden rules."

Fixing the Bot's Endpoint and Navigation

While reviewing, I encountered an issue with the bot's endpoint and noted that the navigation panel looked awkward as it was only half the length. I made some modifications, extending the navigation to full length and fixing the bot's tab link. Both now work as intended.

Enhancing the Files Tab

Another task was to refine the associate feature within the files tab. The associate functionality was supposed to add the feature to the database, but wasn't doing so. Upon examining the issue, I discovered it was attempting to associate the same file twice in OpenAI, causing an error. Cursor was tasked to address this issue for me.

Furthermore, I wanted to ensure if a bot was removed from an association, it would also be erased from the vector store. This process would extend to bots too - deleting a bot should remove it from the database, the assistant, and the vector store. I pasted relevant code snippets to avoid confusion for Cursor. Subsequently, deleting Gym bot 2 confirmed the success of these steps, as it vanished from both the database and the vector store.

Reaching the Goal

With these hurdles overcome, my chatbot platform now stands fully functional. Users can log in, register, create bots, upload files, associate these files with multiple bots, and then interact with the bots to get responses. I feel I am one step closer to developing something genuinely impactful. I look forward to sharing more updates in the next episode.

Thank you for joining me on this journey.

Let's get right into it. First on the agenda is adding a user login and registration feature. I informed the tool I'm using, Cursor, that this is what I want, and it efficiently handled the task. However, it didn't automatically restrict access to the dashboard I built, so I had to prompt it specifically to implement that feature as well.

Once accomplished, a login and registration screen became visible. I opted to sign up first and then attempted to log in using the same credentials. This is where I encountered a roadblock—a persistent error message indicating a mismatch in the expected string pattern. Debugging revealed that the registration input wasn't being recorded in the database, leading to this repetitive error.

I spent some time iterating with Cursor to resolve this. Even when experimenting with different versions of language models like GPT-4o and another variant, I initially couldn't identify the root cause. It finally dawned on me that the registration API endpoint was being protected and requests were rerouted to the login screen, causing the error. It was a testament to the fact that while language models can handle many tasks, there are times when a manual inspection, like reviewing console logs and network responses, is necessary for troubleshooting. Fortunately, once I recognized the issue and communicated it to Cursor, it was quick to correct it.

Having successfully registered an account, I verified its presence in the database and logged in without issues. However, there was a minor hiccup: I wasn't being redirected to the correct pages. After some more prompts to Cursor, I achieved the smooth navigation post-sign-in that I was aiming for.

The next major step was implementing multi-tenancy, where distinct users could have personalized access to their own sets of bots and files. For instance, when user 1 logs in, they should see a different suite compared to user 2. I initiated the process by directing Cursor to ensure logged-in users could only view bots or files they had created.

I went ahead and crafted several test accounts and checked them against the database. In the process, I ran into a 404 error triggered by an endpoint modification—from /bots to just /. Adjusting this was straightforward, and it was addressed promptly. Testing showed that after a minor code change to correctly fetch bots for the logged-in user, different accounts were consistently displaying unique data sets, aligning with the multi-tenancy objective.

With this progress, I'm getting progressively closer to building a fully operational SaaS-based multi-tenant chatbot creator. Soon, it will be robust enough for production use, and I'm thrilled to be expanding its capabilities. Stay tuned for upcoming updates, where I'll continue refining file management and other features, slowly but surely bringing this vision to fruition.

Thank you for joining me on this voyage. Until the next step in our development journey!

Initial Setup and Challenges

To start, I tried using OpenAI's Assistant feature to enhance the bot's capabilities. Initially, I asked Cursor to create a bot that should automatically generate an assistant. However, I encountered an error, and the assistant wasn’t created. Realizing the issue, I decided to switch to the GPT-4o model, as it's better trained with OpenAI's documentation, instead of the Claude 3.5 model. After making this change, I was able to create a new bot, which then appeared under the Assistants feature.

Developing File Search Capability

With the bot successfully created, I wanted to integrate file search functionality within Assistants. The goal was to ensure that when a user uploads a new file, it gets associated with a particular Assistant. In OpenAI's framework, every Assistant can have multiple vector stores, and each vector store can contain multiple files. Thus, I decided to create one vector store for each bot, associating files to the corresponding vector store.

Coding and Configuration

I proceeded to write the code necessary for uploading files. Once the code was in place, I could successfully upload files and see them appear in storage. However, a vector store had not been created. To address this, I modified the code so that a new vector store is created whenever a new bot is set up. Using the GPT-4o model, I inserted code directly from the documentation for a smoother process.

To improve organization, I introduced a "Files" tab that lists all uploaded files, making it easier to manage them. I also corrected a mistake where the system used its own OpenAI key, ensuring it now uses the correct, pre-existing key.

Testing and Troubleshooting

Testing the newly set features, I created a new bot, a gym trainer, and verified its appearance in Assistants. With each Assistant now linked to a vector store, I ensured that user file uploads were stored correctly in the database. This setup allowed me to associate files accurately with their respective vector store IDs, a crucial step for retrieving relevant information during bot interactions.

Finalizing Features

The next step involved adding an association icon next to each file. This function lets me align each file with a specific vector store, ensuring that information retrieval when interacting with the bot is seamless.

Creating new bots, like a gym trainer, further allowed me to test the association process. Upon verification, I could see that the files attached correctly in the vector store and displayed in Assistants, confirming everything was linked as intended.

Conclusion and Future Work

By leveraging these developments, I enabled a feature where users can upload files, connect them with individual bots, and receive tailored responses after retrieving data from these files.

In summary, this session marked a significant advance in building an intelligent file-upload feature for chatbots. I'm excited about the possibilities this opens up and look forward to further enhancements. Thank you for following along with my progress today!

Getting Started with Next.js

The adventure begins with setting up a simple Next.js project. When you start, be sure to choose the 'agent' option instead of the normal one. This crucial step allows the running of commands, which you'll find immensely useful as we proceed. Once configured, you'll be able to view the output in your web browser.

Building an Admin Dashboard

Next, we move on to creating an admin dashboard. This interface will have a look and feel akin to the popular project management tool, Linear. The functionalities include the ability to create, update, and edit bots, a versatile setup to manage your bots efficiently.

Addressing Data Persistence

One challenge you'll encounter is that initially, none of the bot states are saved. This is because there's no real database on the backend. To solve this, we'll set up a database. In this guide, we use SQLite, a convenient lightweight database. However, feel free to choose any database system you prefer, such as MySQL or PostgreSQL. Once implemented, your bots' states will be saved, and they will persist across page reloads.

Creating an API for Bot Communication

With the database in place, the next step is to create an API. This will allow you to invoke individual bots. We'll connect this API to OpenAI to enhance functionality. Additionally, the admin dashboard will feature an option to test messages easily. Connect to OpenAI by securing an API key, allowing interaction with their powerful servers.

Troubleshooting and Enhancements

While testing, you might encounter issues like improper model usage. For instance, there might be a prompt to use the gpt-4o-mini model, although it defaults to the turbo-preview model. It’s vital to ensure the correct model is used. A simple prompt adjustment can direct the system to utilize your desired model, 4o-mini.

Another enhancement is updating the design to a light mode for a more soothing interface and implementing the shadcn library—though its pronunciation is a fun mystery—to achieve a clean, modern look.

Testing With Real Scenarios

With everything set up, it's time to test the bots in action. For variety, you might try scenarios like a gym trainer simulation. The bot's ability to provide a coherent response using the custom instruction will be a testament to the platform's efficacy.

Conclusion and What's Next

This brings us to the end of this section of our chatbot-building journey. In our next installment, we will explore how to upload and integrate your own content into the platform. Stay tuned for more insights and enhancements to your chatbot adventure.

Thank you for exploring the fascinating world of chatbots with me!

Introduction to the Canny Clone

Creating a feature request software like Canny allows users to upvote feature requests, post their own, and comment on any requests. Utilizing Replit simplifies the process, even for those with limited programming knowledge. Let’s dive into how you can leverage this platform to bring your vision to life.

Getting Started with Replit

For this tutorial, we begin by accessing Replit. With the prompt ready, hit start building to initiate your project. At this stage, it’s essential to focus on your initial plan. Adding too many features upfront can complicate things, so let’s keep it simple to start.

The Building Process

Replit makes building intuitive. As the product compilation process completes, it provides real-time results. One distinct advantage of using Replit is its ability to access the actual output and provide screenshots for verification. This helps ensure that your features are functioning as expected.

Testing Your Canny Clone

Now, let’s dive into some testing. Begin by registering with a test account. Though we encountered a minor login issue, it was swiftly resolved, allowing us to proceed with ease. The subsequent steps reaffirm the clone’s functionality—logging in, submitting new feedback, upvoting posts, commenting, and, ultimately, logging out.

Why Replit?

Replit stands out by making the building process as seamless as possible. You don't need deep programming knowledge. Simply input your feature requests, and Replit does the heavy lifting. If you aim to develop internal tools or simple software solutions, then Replit should be your platform of choice due to its simplicity and effectiveness.

Conclusion

Congratulations! By following these steps, you now have your very own Canny clone. This endeavor shows how Replit can transform complex ideas into reality with minimal effort. Whether you're a beginner or an experienced developer, Replit provides the tools and resources necessary to bring your projects to life.

We hope you found this guide helpful in navigating the creation of a Canny clone. Happy building, and thank you for reading!

Are you looking to create a feature-rich user feedback platform? Canny, a popular user feedback software, allows users to create and upvote feature requests with ease. In this post, I'll guide you through building a Canny clone using modern web technologies. This clone will help you gather and manage user feedback effectively.

Setting Up the Project

To get started, we'll create a new Next.js project. Next.js will serve as our frontend framework, enabling seamless integration with our backend services. Go ahead and run your Next.js project. You should see a default page indicating that your setup was successful.

Choosing a Database: Prisma and SQLite

Our next step is to choose a database. We’ll use Prisma, an ORM that simplifies database interactions. For this project, we're integrating Prisma with SQLite, a lightweight and efficient database. Although we're using SQLite here, you can opt for any database that suits your needs. Our database will store all feedback, track upvotes, and manage comments.

Design and UI Customization

With the database set, let’s focus on the UI. We want our Canny clone to mirror the look and feel of the original software. By closely emulating the Canny interface, users will have a familiar experience. Spend some time refining the UI until it matches your envisioned design.

Connecting the Frontend and Backend

Now that our interface is in place, let’s connect it to the backend. Initially, our app might not communicate in real time, so we’ll implement updates to ensure feature requests and upvotes are reflected instantly. Testing is crucial here; check if the data updates without reloading the page.

Testing Functionality: Upvote and Comment Features

Once the connection is established, it’s time to test key functionalities. Start with the upvote feature. After implementing it, try upvoting a feature request and see if it records in the database. Currently, it allows multiple upvotes per user, which we’ll limit to one per anonymous user to avoid skewing results.

Next, introduce individual feature request pages and the ability to add comments. Testing these features ensures the user can engage meaningfully with the feedback platform.

Conclusion

In a few simple steps, we've managed to build a nearly identical clone of Canny's feature request capability. While this tutorial covers the basics, there’s plenty more you can add to enhance your feedback platform. This foundation should get you started on creating an efficient tool for collecting user feedback. Happy coding, and thank you for following along!

However, using AI-powered tools to build software requires a new approach: rethinking how you code (for those who code) and learning how to structure your thoughts (for those who don’t) to create high-quality software. I plan to publish articles and videos for all builders, but having basic technical experience will be very helpful.

If you’d like me to build a particular kind of application, feel free to message me on chat-

Looking forward!

Anant

Kudos makes it easy for you to manage testimonials via multiple sources like Facebook, Twitter, Zendesk and forms. Kudos is a PHP based testimonials management script with many time saving features!

Features

1. Automated Source Pulling

There are multiple sources from which you can pull testimonials into Kudos; I have added the most common sources so that management is extremely simple and quick. Once setup, a team member will take only 5-10 minutes a week to quick accept/reject testimonials. Although most source pulling is automatic, every testimonial must go through a manual acceptance/rejection to ensure only the best testimonials appear on your site.

Source: Twitter
– Automatically pull latest Twitter posts talking about your product/service
– Manually decide to showcase it to the world

Source: Facebook
– Automatically pull latest Facebook posts talking about your product/service
– Manually decide to showcase it to the world

Source: Zendesk
– Automatically pull latest Zendesk customer satisfaction reviews
– Manually decide to showcase it to the world

Source: App Store
– Manually add apps from the App Store (not reviews)
– Automatically pulls app information (icon & description)

Source: Form
– Manually (or via API) add entries into Kudos

Source: Showcase
– Manually highlight key clients (logo & name)

2. Team

You can add multiple team members to Kudos and enable them to accept/reject posts.

There are three different user roles.

User Role: Member
A member can only add entries into Kudos but cannot make them live.

User Role: Manager
A manager can add entries as well as make them live.

User Role: Administrator
The administrator can do all of the above + manage teams + add new sources. The administrator can restrict access to certain sources as well for each member/manager.

3. Posts

Posts is where all the magic happens. On the left side you will be able to see all the channels (i.e. sources) you have access to. For each source there are 3 tabs- Live, Inbox & Add.

Live
These posts (i.e. testimonials) are live and visible to public.

Inbox
These are the incoming posts and need moderation. You can edit them, hide them or make them live.

Add
For certain sources like Form & Showcase, the input is manual. So you will have to manually add an entry. However, for sources like Twitter, Zendesk and Facebook, it is automatic; so no entry is required.

4. Displaying Testimonials

Displaying testimonials requires a little bit of PHP experience. This is because the output is via API only. In future releases, I will write a method to show it directly using Javascript. But for now, it’s via API.

Add the following two functions to your code:

define('KUDOS_URL','URL_WITH_TRAILING_SLASH');
define('KUDOS_API','API_KEY_MENTIONED_IN_CONFIG_FILE');

function kudos($url, $data) {
    $params = '';
	foreach ($data as $key => $value) {
		$params .= $key.'='.$value.'&';
	}

	$params = trim($params, '&');

		$ch = curl_init();
		curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
		curl_setopt($ch, CURLOPT_MAXREDIRS, 10 );
		curl_setopt($ch, CURLOPT_URL, KUDOS_URL.$url.'/'.KUDOS_API.'?'.$params);
		curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "GET");
		curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-type: application/json'));
		curl_setopt($ch, CURLOPT_USERAGENT, "MozillaXYZ/1.0");
		curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
		curl_setopt($ch, CURLOPT_TIMEOUT, 10);
		$output = curl_exec($ch);
		curl_close($ch);
		$decoded = json_decode($output);

		return $decoded;
}

function kudos_post($url, $data) {
    $params = '';
	foreach ($data as $key => $value) {
		$params .= $key.'='.urlencode($value).'&';
	}

	$params = trim($params, '&');

	$ch = curl_init();
	curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
	curl_setopt($ch, CURLOPT_MAXREDIRS, 10 );
	curl_setopt($ch, CURLOPT_URL, KUDOS_URL.$url.'/'.KUDOS_API.'?'.$params);
	curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "GET");
	curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-type: application/json'));
	curl_setopt($ch, CURLOPT_USERAGENT, "MozillaXYZ/1.0");
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
	curl_setopt($ch, CURLOPT_TIMEOUT, 10);
	$output = curl_exec($ch);
	curl_close($ch);
	$decoded = $output;

	return $decoded;

}

The first function is to pull results and the second function is to send posts (e.g. for manual entry).

Once this is done, you can pull results using the following function:

$testimonials = kudos('posts',array('id'=>KUDOSID,'limit'=>'50', 'offset'=>'0', 'orderby' => ''));

The KUDOSID will have to be manually found out. In Posts section (in Kudos), you can see the links with the ID (the number after the last / in the URL). Once you have the data, you can iterate through the array and display it wherever you like on your site. Since all the processing is done at PHP level, the code is super SEO friendly (unlike some Javascript).

Requirements
1. PHP 5+
2. mySQL

Download

Kudos is hosted at GitHub

Getting Started

Download and follow the instructions in install.md file

Next Steps

Feel free to contribute to the code. I have added some next steps in the todo.md file. Eventually I will create a testimonials plugin for WordPress.

Comments/Suggestions?
Do let me know your suggestions on how we can improve this code or any other features you would like to add.

Spread The Word
If you like what you are reading, then please help spread the word by re-tweeting, blogging or using the ShareThis button below. Thank you.

If you are using Typekit to power fonts on your website, then you would have noticed the flash of unstyled text problem (or FOUT) in Chrome 50. The folks at Typekit have written a fairly long post about it; TL;DR- it’s not really considered a bug so the problem is here to stay.

There are a couple of fixes available for this problem but most posts are over a year old.

The Solution

I’ve modified some existing code by Sebastian Kippe (read his blog post) and added a fix so that for a given session, if the browser is unable to load the fonts, then it will not try again till end of session. And if it is able to load the fonts, then the text will be invisible until the font is loaded.

Add the following just before the closing </HEAD> tag of your site template-

<script>
		(function(d) {
			loadFonts = 1;
			if(window.sessionStorage){
				if(sessionStorage.getItem('useTypekit')==='false'){
					loadFonts = 0;
				}
			}

			if (loadFonts == 1) {
					var config = {
						kitId: 'XXXXXXXX',
						scriptTimeout: 3000,
						async: true
					},
					h=d.documentElement,t=setTimeout(function(){h.className=h.className.replace(/\bwf-loading\b/g,"")+" wf-inactive";if(window.sessionStorage){sessionStorage.setItem("useTypekit","false")}},config.scriptTimeout),tk=d.createElement("script"),f=false,s=d.getElementsByTagName("script")[0],a;h.className+="wf-loading";tk.src='https://use.typekit.net/'+config.kitId+'.js';tk.async=true;tk.onload=tk.onreadystatechange=function(){a=this.readyState;if(f||a&&a!="complete"&&a!="loaded")return;f=true;clearTimeout(t);try{Typekit.load(config)}catch(e){}};s.parentNode.insertBefore(tk,s);
				}
			}

		)(document);
		</script>

<style>
		.wf-loading	p, .wf-loading h1, .wf-loading h2, .wf-loading h3, .wf-loading h4 {
			visibility: hidden;
		}
		.wf-active	p, .wf-active h1, .wf-active h2, .wf-active h3, .wf-active h4 {
			visibility: visible;
		}
		.wf-inactive	p, .wf-inactive h1, .wf-inactive h2, .wf-inactive h3, .wf-inactive h4 {
			visibility: visible;
		}
</style>

You will only need to replace ‘XXXXXXXX’ in the above with your actual Typekit Kit ID. You can add more styles if need be.

Flow chart

1. The CSS styles hide all visible text (modify to add more styles if required)
2. The script tries to load the Typekit Javascript file
3. If the script is unable to do so within 3 seconds, it loads the standard fonts and sets a local storage variable to avoid trying to load the fonts again for the current session
4. All future calls for the same session show the standard fonts

How to test if font’s don’t load?

To check how your site will render if the Typekit fonts don’t load, simply replace “use.typekit.net” with “donotuse.typekit.net” (or anything else) in the above code. Don’t forget to replace it back once you’re done testing!

That’s all folks!

Discuss, Share & Subscribe

Do let me know your suggestions on how I can improve this code. If you like what you are reading, then please help spread the word by re-tweeting, blogging and sharing this. Thank you.

SocialTurn makes it easy for teams to publish to social media. Drop the manual sharing of social passwords to each team member, and worrying about your security and get SocialTurn, the easy and free way to publish social updates for your whole team. SocialTurn is a PHP/mySQL based Buffer clone.

Features

1. Social
– Auto schedule social posts depending on day and time
– Share important posts via multiple accounts
– Use suggestions for posting generic updates
– Quick and simple updates and management

2. Team
– Manage multiple team members
– Assign privileges to members
– Give access to specific Twitter/Facebook accounts to each user
– Invite a new team member directly via email

3. Connect
– Manage multiple Twitter & Facebook accounts
– Reconnect/delete old accounts with ease

Demonstration
Launch SocialTurn – Buffer Clone Demo

Screenshot

Requirements
1. PHP 5+
2. mySQL

Getting Started
Download and follow the instructions in README.md file

Download
SocialTurn is hosted at GitHub

Comments/Suggestions?
Do let me know your suggestions on how we can improve this code or any other features you would like to add.

Spread The Word
If you like what you are reading, then please help spread the word by re-tweeting, blogging or using the ShareThis button below. Thank you.

If you are using a shared host like GoDaddy, Asmallorange etc. they have limited options when it comes to uploading your code to their servers. Most will provide only FTP access. If you are using Git (or GitHub) for your development purpose, it becomes a huge inconvenience to use an FTP client to upload the files manually. If you have a large set of files, then you also need to manually upload only the changed files.

With this solution, you will not need to use an FTP client.

Step 1

Begin with downloading msysgit for Windows. At the time of writing this, the latest file is “msysGit-fullinstall-1.8.4-preview20130916.exe”. Click on the link below to download.

On completion, close this window and create a shortcut to “c:\msysgit\git-cmd.bat” (Note this is different from msys.bat)

The Workflow

Committing Changes

I use GitHub so I prefer using their simple tool for committing changes. You can use the command-line version as well if you need more control. If you need a good guide to learn Git, I suggest:

Easy version control with Git

Pushing to FTP

1. Simply launch git-cmd.bat
2. This will load a standard command prompt. Go to your working folder (which you want to synchronize) [must be git repo].
3. For the first time, add your FTP details

git config git-ftp.user demouser
git config git-ftp.url ftp.example.com/demofolder
git config git-ftp.password demopassword

4. To initialize, run the following command for your first commit only

git ftp init

5. After this, for all subsequent commits

git ftp push

That’s all folks!

Discuss, Share & Subscribe

Do let me know your suggestions on how I can improve this tutorial. If you like what you are reading, then please help spread the word by re-tweeting, blogging and sharing this tutorial. Thank you.

1. Database versioning
2. Hosting, Database & DNS

Part 1: Database versioning

In the first part, we discuss about creating separate databases for every client. Now the problem is that these databases are empty and we need to fill them with some basic data + schema. The problem of creating this in the site code, is when you update your schema, you will have to manually update all the databases. This can be extremely tedious and difficult to achieve.

Thus to solve this problem, we assume our DB is empty. Then we create our version 1 of the schema and save it as db/1.sql. This will be our base i.e. when the user first visits the client’s site, it will run this SQL to create the require schema. Next version will be 2.sql (which may add/drop tables etc.) and so on.

In our app configuration file, we will add a variable (somewhere at the top) and set it to the latest schema version.

$currentdbversion = 5;

Then after the DB connection, we will add the following code:

...

mysql_selectdb(DB_NAME,$dbh);

// Success! Now we can continue to use the app as-is!

$sql = ("select * from cometchat_settings where name = 'dbversion'");
$appsettings = mysql_fetch_row($sql);

$dbversion = 0;

if (!empty($appsettings['value'])) {
   $dbversion = $appsettings['value'];
}

while ($dbversion < $currentdbversion) {
    $dbversion++;
    if (file_exists(dirname(__FILE__).'/db/'.($dbversion).'.php')) {
        include_once(dirname(__FILE__).'/db/'.($dbversion).'.php');
    }
}

In 1.sql, you can add your SQL queries, and add the bottom you will add:

<?php

$sql = ("CREATE TABLE  `app_settings` ( `name` varchar(255) NOT NULL,  `value` text NOT NULL, PRIMARY KEY  USING BTREE (`name`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;");
$query = mysql_query($sql);

// Add other SQL queries

$sql = ("REPLACE INTO `app_settings` (name,value) values ('dbversion','1')");
$query = mysql_query($sql);

In 2.sql and all other SQL files, it will be:

<?php

// Add other SQL queries

$sql = ("REPLACE INTO `app_settings` (name,value) values ('dbversion','2')");
$query = mysql_query($sql);

So the workflow is as follows:

1. The site code only creates the DB. It does not populate the DB with any data/schema.
2. When the client visits the app for the first time, $dbversion is 0, so 1.sql is executed.
3. When you make changes to your SQL DB, you simply update $currentdbversion & add the $currentdbversion.sql file to the db folder
4. When the app is run the next time, it will check if the SQL dbversion is lower than $currentdbversion; if yes, it will run all the SQL files till it reaches the latest version.

Part 2: Hosting on Elastic Beanstalk

Hosting on Amazon’s Elastic Beanstalk is fairly simple.

Step 1

Signup for Amazon AWS and then go to “Elastic Beanstalk” and create a new application. Zip all your PHP code (for your app) and then attach it while creating:

Step 2

Enter a URL for your app; I have used “mydummyapp”.

Step 3

t1.micro is sufficient to begin with and will keep your costs low. Select it and then proceed with creation.

Step 4

Go to “RDS”, “Launch new DB instance” and then create a new instance.

Step 5

Create a DB for your site (which will be used to store all clients info). The client specific DBs will be created on the fly (in the same instance).

Once completed, add the connection details to your app and test if the connection is working fine. If you are unable to connect, then edit the “default” Security Group and add “CIDR/IP: 0.0.0.0/0”. This will allow you to connect to the instance from any IP. Later, you can modify this to only certain IPs.

Step 6

Go to “Route 53” and “Create Hosted Zone” and enter your domain URL. Then double click on the listing and then “Create Record Set”.

Once done, get the server IP for your site hosting (from Asmallorange/Rackspace/site-host) and two A records:

Finally, update your nameservers to point to those mentioned by Amazon.

Once this is done, you can visit http://mydummyapp.elasticbeanstalk.com and check your app. You can use any third-party host like Asmallorange or RackSpace to host your SaaS site. You do not need to use Amazon Beanstalk to host your SaaS site.

That’s all folks! Now you have successfully setup your server (Beanstalk), your DBs (RDS) and your DNS (Route 53). You should be now ready to start testing your app along with your site.

Where do we go from here?

We have achieved a lot using this tutorial (and part 1). We have setup our app, site and have configured Amazon’s services to host our app. In the next part, we will talk about scaling and other tips & tricks.

Discuss, Share & Subscribe

Do let me know your suggestions on how I can improve this tutorial. If you like what you are reading, then please help spread the word by re-tweeting, blogging and sharing this tutorial. Thank you.

To get a notification when the next part is ready, please subscribe using the form at the bottom of this page.

We will be looking at…

1. Creating your app

The app is the product that you are going to sell. If you already have this app ready, you will only have to modify it so that it is compatible for multiple clients. The app is the front-end for your client’s end-users.

2. Creating your SaaS site

The site is the front-end for your clients. They will be using your site to signup for the app.

3. Hosting et al.

We will talk about how to host your app + site, how to ensure scaling, setting up DNS & SSL, database versioning etc.

Part 1: Create your app

Before you begin with selling your product, you need to have a product. Let us first try and understand the SaaS architecture. Every app consists of two parts: code & data. Now, every client has end-users; the data is shared between these end-users and (mostly) not with other clients’ end-users. So every set of end-users (of each client) should access a different set of data. In most cases, the code used by all the clients can be the same.

Now there are various ways in which a SaaS app can be designed:

Option 1 – Single database, single code-base

Use a single database and store all client data in a single database. You will have to add a field like “clientid” in all your tables and modify all your SQL queries to select the correct “clientid”. If you already have a single tenant app, then heavy modification is required in the code.

Advantages: Easy to manage database & updates; no duplication.
Disadvantages: If you miss out a “clientid” in the SQL query, it may result in issues with another client.

Option 2 – Multiple database, single code-base

Create a separate database for every client. No modification is required to your existing single-tenant codebase. You will only have to modify the configuration file to select a database depending on the client.

Advantages: Very little codebase modification, easy to ensure client data does not get mixed.
Disadvantages: Multiple databases to manage so in the event of DB schema updates, you will have to update each and every database.

Option 3 – Multiple database, multiple code-base

Create a separate database & duplicate the complete code for every client. No modification required at all.

Advantages: No codebase modification, easy to ensure client data does not get mixed, easy to perform client specific modifications.
Disadvantages: Multiple databases/code to manage so in the event of DB schema/code updates, you will have to manually update for each client.

There are a number of articles discussing which approach is the best but option 2 helps us develop a scalable SaaS solution in the quickest possible way. So we will stick to option 2 for this tutorial.

If you already have an app then you will only have to modify the configuration file as below. If you do not, then make sure your configuration file looks something like below and the rest of the app can be however you like it.

Let us begin with the PHP part. You should be ideally using a framework like Symfony or Zend to create your app. To simplify, I am only going to be talking about config.php:

This is how a simple standard config.php file looks: (usually DB connection is not part of this, but for a clearer explanation, I have added it)

<?php

define('DB_SERVER','localhost');
define('DB_PORT','3306');
define('DB_USERNAME','root');
define('DB_PASSWORD','password');
define('DB_NAME','dummyapp');

$dbh = mysql_connect(DB_SERVER.':'.DB_PORT,DB_USERNAME,DB_PASSWORD);
if (!$dbh) {
	echo "Oops! Something went horribly wrong.";
	exit();
}
mysql_selectdb(DB_NAME,$dbh);

In the above code, when the user visits a PHP page, it calls config.php, which stores the database configuration & connects the database. Then the remaining PHP files, calling this configuration file, can connect to the DB.

The problem in the above code is that it is built for a single client (with a single set of end-users). We need to modify this code so that for each client, a different database is used. So depending on how the app is called (i.e. depending on the URL), we will connect to a different database. If you look at SaaS apps online, you will find that they assign a unique sub-domain to every client. This technique will come in handy.

So if your site is mydummyapp.com, then when a client registers, he will be assigned a URL like anantgarg.mydummyapp.com, yourname.mydummyapp.com etc. Now, all end-users of the client will connect to the same sub-domain.

To make our app SaaS friendly we need to check the sub-domain and then accordingly connect to a database. We will perform the following checks:

1. Let the end-user visit the app using *.mydummyapp.com (DNS configuration in next post)
2. Check a central table if the sub-domain is registered; if yes, to whom? Then fetch the DB details
3. Connect the end-user to the client’s DB

Here is how a modified config.php will look:

<?php

$data = explode('.',$_SERVER['SERVER_NAME']); // Get the sub-domain here

// Add some sanitization for $data

if (!empty($data[0])) {
    $subdomain = $data[0]; // The * of *.mydummyapp.com will be now stored in $subdomain
}

// Contact a central database (which stores information about all clients

define('SITE_DB_SERVER','localhost');
define('SITE_DB_PORT','3306');
define('SITE_DB_USERNAME','root');
define('SITE_DB_PASSWORD','password');
define('SITE_DB_NAME','dummysite');

$sitedbh = mysql_connect(SITE_DB_SERVER.':'.SITE_DB_PORT,SITE_DB_USERNAME,SITE_DB_PASSWORD);

// Get client's DB details (make sure $subdomain is already sanitized)

$sitemysql = mysql_query('select id,dbusername,dbpassword from clients where subdomain = '.$subdomain.');
$appdata = mysql_fetch_row($sitemysql);

// You can add caching code here to skip the above DB call

if (empty($appdata['id'])) {
    // If the client does not exist i.e. the end-user types the wrong sub-domain

    echo "Oops! Sorry, we are unable to find you! Please email us at support@mydummyapp.com";
    exit();
}

define('DB_SERVER','localhost');
define('DB_PORT','3306');
define('DB_USERNAME',$appdata['dbusername']);
define('DB_PASSWORD',$appdata['dbpassword']);
define('DB_NAME','dummyapp_'.$appdata['id']);

$dbh = mysql_connect(DB_SERVER.':'.DB_PORT,DB_USERNAME,DB_PASSWORD);
if (!$dbh) { exit(); }

mysql_selectdb(DB_NAME,$dbh);

// Success! Now we can continue to use the app as-is!

If you are modifying your existing app, then you only need to modify your configuration file and make it similar to the above. The rest of the app should not need any modification (as long as you are not saving any files). If you have files, then you will have to modify the file upload code and add a folder e.g. /uploads/$subdomain/$filename.

If you are testing on localhost, you can simply add something like the following to your hosts file:

127.0.0.1      test.mydummyapp.com
127.0.0.1      test2.mydummyapp.com

Part 2: Create your SaaS site

I assume you can create a simple SaaS site with user registration. On your registration page, you will need to have something like:

Username: _ _ _ _ _ _ _ _
Password: _ _ _ _ _ _ _ _
Subdomain: _ _ _ _ _ _ _ _ (.mydummyapp.com): 

You will need to create a common DB (e.g. dummysite) with a table called “clients”. In your real site, you will also need other tables like “subscriptions” which will hold payment information.

create table clients (
  id int default 0 auto_increment,
  username varchar(50),
  password varchar(255),
  subdomain varchar(50),
  dbusername varchar(50),
  dbpassword varchar(50)
)

Now for every client who signs up on your site, you will have to add an entry into the above table. You will also have to create random dbusername & dbpassword. And finally, you need to create a new DB for this client.

The PHP code for that will be:

// Connect to database instance (which stores all app DBs)
$dbh = mysql_connect(DB_SERVER.':'.DB_PORT,DB_MASTERUSERNAME,DB_MASTERPASSWORD);

// Create DB ($id will have value of client's inserted ID)
mysql_query("CREATE DATABASE mydummyapp_".$id."",$dbh) or die(mysql_error());

// Create user and grant all privileges for the above DB
mysql_query("GRANT ALL ON mydummyapp_".$id.".* to  ".$dbusername." identified by '".$dbpassword."'",$dbh) or die(mysql_error());

Once this is done, you should be able to put all the pieces together and get your first SaaS app up and running.

Part 3: Putting it all together

The site structure will be as follows-

www.mydummyapp.com: SaaS site (where the client registers)
*.mydummyapp.com: SaaS app (catch-all points to the actual app)

The workflow is as follows:

1. The client visits www.mydummyapp.com
2. The client registers on the site
3. The site creates the a DB (and user) for the client (and adds an entry in the site’s DB)
4. The client then uses the new URL (i.e. clientsubdomain.mydummyapp.com) for himself & his end-users
5. The end-users directly visit clientsubdomain.mydummyapp.com which is basically the app using the client’s DB

Where do we go from here?

We have achieved quite a bit using this tutorial. We have setup our app and site and can now allow clients to register and use the app. In the next parts will we discuss about managing the databases, setting up DNS, handling hosting, scaling and other tips & tricks.

Discuss, Share & Subscribe

Do let me know your suggestions on how I can improve this tutorial. If you like what you are reading, then please help spread the word by re-tweeting, blogging and sharing this tutorial. Thank you.

To get a notification when the next part is ready, please subscribe using the form at the bottom of this page.

I was referenced in the WSJ article- Google’s iPhone tracking regarding my cross-domain cookies post.

For my technical audience, here is a detailed version of how my code was actually used.

So let us begin from scratch… what are cookies?

Cookies (data on your computer used to identify you) are stored whenever you visit a site. Usually, this data is used to keep you logged into a site or to figure out if you are a repeat visitor.

This is fine and in-order for the web to function in it’s current state, in many ways, essential.

In the above diagram, when you visit siteA.com, a cookie is set for siteA.com on your computer.

When you visit siteB.com, a cookie is set for siteB.com on your computer.

But siteB.com, CANNOT read the data from the cookies set in siteA.com and vice-versa. Thus siteB.com does not know if you ever visited siteA.com or what you did there.

Let’s introduce the ad-companies

Ad-companies started displaying ads on sites depending on the content of the page. So, if you are a webmaster, you add a line of JavaScript code and a neat looking advertisement is displayed on your site page.

But the information on the page is not enough to generate targeted ads. So the ad-companies wanted to know where you’ve been before.

Now here is where the privacy issue unfolds.

Tracking your moves

Inorder to track you, as you moved from one site to another (both displaying sites ads from the same ad-company), the companies need to store cookies.

The problem is that cookies set on one site CANNOT be read by another site. In other words, cookies set on siteA.com cannot be read by siteB.com.

So the work-around used is to store a third-party cookie (i.e. a cross-domain cookie). When a user visits siteA.com, a cookie is not only set for siteA.com but also for a common domain which is accessed by all sites that use the ad-company’s code.

Thus, siteA.com, siteB.com and all other sites displaying ads from adsite.com, store and access the same third-party cookie.

So when you visit siteA.com, a third-party cookie is created on adsite.com. When you visit siteB.com, the same cookie is read.

Thus adsite.com now knows that you have been to siteA.com before going to siteB.com. On the basis of this knowledge, a targeted ad can be shown. For an ad-company which provides ads to only two sites, this is not very useful. But imagine if you have 70% of the sites using your code.

Then, nearly most of the times, the same cookie can be read and your movements can be tracked as you browse through the internet. So now, the ad-company knows exact what kind of sites you are visiting and serve ads accordingly.

But why does the WSJ article only talk about Safari?

Safari, by default, does not allow third-party cookies to be created.

However, most major browsers- Firefox, Internet Explorer (using the correct header tags), Chrome etc. do ALLOW setting third-party cookies.

Where does your technique come in?

The technique I posted two years ago, allows setting third-party cookies for Safari as well. This helps in offering a consistent user experience irrespective of the browser used.

Note that other browsers already allow creation of third-party cookies. So Safari is the only exception.

How was this discovered?

A Stanford researcher, Jonathan Mayer found that many large companies like Google, MIG, PointRoll etc. used a variation of my technique to circumvent Safari’s policy.

Infact, Facebook’s official developer best practices article linked to my post (the page has since been removed).

You must remember that this issue affects Safari users ONLY.

Other browsers already allow third-party cookies and thus they CAN track you as they do NOT have any such policy.

How do I protect myself? Should I disable cookies?

NO. Do not disable cookies altogether. This will cause most of your sites (which have a login system) to stop working.

Third-party cookies also have a number of other uses like logging in users to third-party sites and are NOT always used for tracking. They cannot steal your data (a myth noted by some users in comments).

If you want, you can disable third-party cookies in browsers. Dennis O’Reilly has written a guide on how to disable third-party cookies for major browsers.

You may also want to use incognito/private browsing modes when using a public PC.

Questions/Suggestions?

If you have any questions about how this affects you or need further explanation, feel free to post a comment or contact me.

As your site grows, so do your chances of getting hacked. Most of these hacks are due to known exploits in existing open/closed source software. One of the biggest worries is a user getting full access to your site using a simple PHP upload.

So what’s the solution?

This is no silver bullet but if a user uploads any malicious files to your server, you should be able to quickly check what files have been modified/added.

PHP Exploit Scanner

The Exploit Scanner is a single PHP file which generates MD5 hash for all files of a particular software and then allows you to compare that with software you think has been modified.

Sample Usage

Lets say you want to check for any exploits in your WordPress installation

1. Download a fresh copy of WordPress from the official site (make sure you download correct version)
2. Upload WordPress to your server/localhost
3. Run exploitscanner.php?action=generate in the new WordPress folder (you do not need to install WordPress)
4. Check filehashes.php and verify output is correct (i.e. an array of files with their hashes)
5. Now upload exploitscanner.php and filehashes.php to your live WordPress folder
6. Run exploitscanner.php?action=scan to generate a list of modified/added files
7. Check output of scanresults.txt

Generating Hashes

Upload exploitscanner.php to the folder for which you want to generate file hashes and then point your browser to:

http://www.yoursite.com/untouchedsoftware/exploitscanner.php?action=generate

Only output is filehashes.php

Note: Be sure that the software is not already exploited. Ideally use a fresh copy from the software creators (make sure you check the version)

Scanning For Exploits

Upload exploitscanner.php to the folder for which you want to check file hashes and then point your browser to:

http://www.yoursite.com/hackedsoftware/exploitscanner.php?action=scan

Only output is scanresults.txt
Legend- F: New file | M: Modified file

First search for all .php files to see what is changed. If the file is tagged M, you can use a difference tool like WinMerge to find out what has changed.

Download

Download PHP Exploit Scanner free

License

Exploit Scanner is licensed under MIT license. Let me know if you make any interesting use of the script.

Comments/Suggestions?

If you would like to assist in creating a community where users can quickly download filehashes.php for their software then feel free to contact me using the form below.

Do let me know your suggestions on how we can improve this code or any other features you would like to add.

Future Updates

1. Improve recursive function to avoid time out on shared servers
2. Create a community where users can upload hashes for known software like phpBB, vBulletin etc.
3. Add GUI
4. Database integrity
5. Malicious code insertion in template files

Spread The Word

If you like what you are reading, then please help spread the word by re-tweeting, blogging or using the ShareThis button below. Thank you.

The Problem

Safari does not allow cross-domain cookies. In other words, if on X.com, you load an iFrame with contents of Y.com and set a cookie in the iFrame, Safari will not save the cookie. This problem also occurs in IE6/7 but can be resolved by sending a P3P header.

The Solution

I am not entirely sure why this works, but the cookie gets saved if a post is made to the iFrame. This solution relies of jQuery but can be adapted to any other.

Here is the code that goes on the remote domain:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js" type="text/javascript"></script>
<script>
var isSafari = (/Safari/.test(navigator.userAgent));
var firstTimeSession = 0;

function submitSessionForm() {
	if (firstTimeSession == 0) {
		firstTimeSession = 1;
		$("#sessionform").submit();
		setTimeout(processApplication(),2000);
  	}	
}

if (isSafari) {
	$("body").append('<iframe id="sessionframe" name="sessionframe" onload="submitSessionForm()" src="http://www.yourdomain.com/blank.php" style="display:none;"></iframe><form id="sessionform" enctype="application/x-www-form-urlencoded" action="http://www.yourdomain.com/startsession.php" target="sessionframe" action="post"></form>');
} else {
	processApplication();
}

function processApplication() {
	alert('Session has been set. Now you can start your application!');
}
</script>

The contents for startsession.php would be as simple as:

<?php
header('P3P: CP="IDC DSP COR CURa ADMa OUR IND PHY ONL COM STA"'); 
session_start();

To make sure that your site is compatible with IE6/7, always output the following header:

<?php
header('P3P: CP="IDC DSP COR CURa ADMa OUR IND PHY ONL COM STA"'); 

Unfortunately, there is no way to find out when the browser has completed submitting the form. Thus, I have placed a delay of 2 seconds. This form needs to be submitted only once per user session. Then you can set your session data in PHP and it will be picked up by your remote domain. You can adapt the same example if you want to set cookies instead of starting a PHP session.

Comments/Suggestions?
Do let me know your suggestions on how we can improve this code.

Spread The Word
If you like what you are reading, then please help spread the word by re-tweeting, blogging or using the ShareThis button below. Thank you.