Member Avatar for flynismo

Hello all!

I am very new to php...still trying to grasp the fundamentals of it. I have a scenario that I hope I could make work, because it will save me A LOT of time and heartache.

Here's the deal....I have two different websites. However (this may be confusing because I may not be explaining this clearly enough), the one is an extension of the first. In other words,
www.ABC.com is my main website, and is a totally seperate site that is accessed like this-

Now, I already have the database for (the extended site) setup, while I have done nothing with the main site yet other than making templates for it and such. I am almost ready to start doing the "dirty work", i.e. making the site functional. I'm wondering, once the site is live and starts attracting members, is it possible to have the members from both sites register into the same database? Keep in mind, the extended site () is already setup up and ready to go (because it was a script I purchased), so can I have the two share the same database? If so, could someone show me how this is done or point me in the right direction?

Thanks for any help!

  • 3 Contributors
  • 2 Replies
  • 108 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by cerberox

Dani AI

Generated

A few clarifying points based on 's description and the short replies from and , followed by practical steps you can apply immediately.

Decide the auth surface first: if both sites live under the same top-level domain (for example a path or subdomain of the same host) you can share session cookies by setting the cookie domain accordingly; if they live on different top-level domains you cannot share browser cookies and will need a central login/token flow (redirect to an auth endpoint that issues signed tokens). See PHP docs for cookie and session parameters: session_set_cookie_params and setcookie.

Schema and migration guidance: make one canonical user identifier (an integer primary key) and put site-specific profile columns into a separate profiles table that references that id. Adding a site identifier avoids collisions and keeps the core auth fields consistent. Example schema changes:

ALTER TABLE users ADD COLUMN created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;

CREATE TABLE site_profiles (
  id INT AUTO_INCREMENT PRIMARY KEY,
  user_id INT NOT NULL,
  site_key VARCHAR(50) NOT NULL,
  profile_data JSON,
  FOREIGN KEY (user_id) REFERENCES users(id)
);

Password & coding best practices: never store plaintext or unsalted hashes. Use PHP's password_hash/password_verify and rehash on first login if the legacy app used a different algorithm. Use prepared statements (PDO) for queries to avoid injection. See password_hash and the OWASP Password Storage Cheat Sheet.

Practical checklist: back up both databases before any change; test on a staging server; reconcile column names (write a small migration script to map fields); ensure unique constraints (email/username) won’t collide; confirm DB user privileges and connection settings; and log auth failures while testing. If cross-server latency becomes a problem later, move the auth store to a single well-indexed server and access it from both sites.

Recommended Answers

All 2 Replies

Member Avatar for jbennet

yes, just use the same users table

Member Avatar for cerberox

you can conect 2 databases at the same time to share the users table but consumes resources.

if you want do that, need make a database whit be capable to chose between the sites and show the data that corresponds.

show your structure and we can talk about it.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.