For security reasons you can't create cookies or read cookies for another domain...

The best solution I guess if all the 5 domains contains the same information, redirect all to the corbensproducts.com and work only with the corbensproducts.com

If each contains a different content, you might want to add subdomain to the corbensproducts.com and it will make your work much easier..

>>> read cookies for another domain
I know that... and that's not what I want to do...

>>>create cookies for another domain
Got you there... I can not create the cookie for the domain till the client is in the domain... Yes?


>>>5 domains contains the same information

no they do not...

>>>you might want to add subdomain

that won't work either... I understand the point you are making... but I'm interested in ways around it... ie... since it's the same script creating the different cookies for each domain now... may-be the value could be passed over?

The point is that the script IS creating cookies for the other domains... as the client moves to the to the "other" domain...

thou it's the sever side script forming the content... they are related but not the same site... But they are the same DB, the same server, uses the same .htaccess, etc...  and the cookies are the same name for the client, they just need to ??have the same value??

it is more of a technicality type thing... they act as if they were subdomains... with out having to be a subdomain...

Hope this all make better sense

>>>>make your work much easier
Thou I appreciate that,  I'm trying to find a new way to handle related domains... may-be this is to hard for people in here???.. was not sure so I took a shot...

Thank you for the help...
jeremyBass

If I were asked to summarize the situation, I would have to say that this organization of interlinked but independent domains is a design flaw.  There may not be a really good way out of this.  On the cookies issue, you will find that corbensproducts.org is as different from corbensproducts.com as it is from yahoo.com.  And that, as they say, is that.

You might find that you can pass a token in your URLs to carry some kind of homegrown session variable.  You can use this variable as an index into the data base, and keep your state-ful information in the DB.  This is conceptually similar to what PHP does when session cookies are not available -- it puts the PHPSESSID into the URL of the links.  Unfortunately the straight PHP solution will not do much for you, because PHP thinks that different domains should not share the same session.

HTH, ~Ray

Hmm... Maybe there is a way around this.  But it will mean a lot of fiddly programming.  Here is the idea...

1. on every site except the .COM version, make every URL redirect to the same page on the .COM site, carrying with it the TLD of the "from" page in the GET string.

2. on every page of the .COM version, check the incoming TLD and load the appropriate page via require_once();

<?php // REDIRECT TO THE .COM PAGE WITH AN INDICATOR OF MY TLD
$tld  = strtolower(end(explode('.', $_SERVER["HTTP_HOST"])));
if (ereg('?', $_SERVER["REQUEST_URI"])
{
   $glue = '&TLD='; 
} else {
   $glue = '?TLD=';
}
$uri = $_SERVER["REQUEST_URI"] . $glue . $tld;
header("Location: http://corbenproducts.com/$uri");
exit;
?>
 
 
 
<?php // ANALYZE TLD AND ACT DIFFERENT
if ($_GET["TLD"] == "net") require_once( /* .NET version */); die();
if ($_GET["TLD"] == "org") require_once( /* .ORG version */); die();
// ETC...

Select allOpen in new window

Ray_Paseur... You are starting to think Outside the box... One thing that I didn't mention ... mostly because I didn't think about it till now was that there is only one page.  Index.php.  Every page is that page.  Your idea is how this is working... so I just need to give the right cookie back.  


Hope that makes sense... You know you can visit it... it's a real site.... a test site for the big dog site.. but real...


Thank you for the help...
Jeremy

Just curious, would you please post your solution?  When a question gets deleted after this much dialog, we would like to know.  Thanks, ~Ray

>>>>Just curious, would you please post your solution?

I don't have one yet... I just thought since no one was posting on this and the support people seem to hate dead posts I would delete it...

The way I think I'm going to solve this is by shoving the session in the db and that way I can pull the sorted value and pass it to each cookie... so  as you move thru the site/sites you still get a cookie for each domain but it's the same value for the user... so the cms will still think your logged in...  and it should be secure.

That's the thought... and I have to figure out how to do it in the realm of the CMS but.. I think I can...

I wish I had the solution to post..
:-)

jeremy

Well, good luck.  You'll want to be very good at version control and testing.  If it were my issue, I would choose a design change now rather than risk being forced into a design change at some time in the future.  You might want to post this question, and a link to this EE entry in the CMSMS forums now, before it is too late.

As far as using EE goes, we are volunteers who work for points here, so if you don't intend to award points, it is probably best not to post the questions in the first place ;-)  The solution I showed at #23290753 will implement a working answer to your originally posted question.  But then there is the whole issue of what will happen to your scripts when CMSMS sets about making SEO-friendly URLS.

As the guidelines say, sometimes the correct answer is "you can't do that"
https://www.experts-exchange.com/help.jsp#hi403

>>>so if you don't intend to award points
I always intend to award points but I was told before not to award point if the question was not answered so there is no false solutions... I use to give the points for trying... And I thought that was what they meant...

>>>sometimes the correct answer is "you can't do that"
true... but I don't believe this is one of those times... thats a personal view and I could be wrong... time will tell..

>>>solution I showed at #23290753 will implement a working answer to your originally posted question

I respectfully disagree... that is not the solution I was looking for... in fact as I stated that is how the site mostly works anyway... may-be not as simple as you wrote but all domains are served via one page in a much more controlled way... all but the cookies... the one page is the index.php of the root directory...

>>>CMSMS sets about making SEO-friendly URLS

If you work with CMSMS then you know it already supports SEO-friendly URLS in most mods... Plus I'm a wiz with the templates and what not so I'm not sweating it... ;-)

You need to know that it's one install handling all the domains... it wouldn't make a diff if it was 2-100 domains... The way I set it, CMSMS handles it well... in fact I was the dev of this trick& first to came up with how to do this in the CMSMS world... now there are draw backs but that is what I'm working on... this question in point...

If you think I'm not awarding you the points for some reason... Let me tell you I have unlimited points and give them away freely... when they are within the rules... and as v_mod told me ... this is not in the way the rules would allow for points... If I'm wrong I'm sorry... may-be they can point that out&

but since you killed the delete process, I'll let it sit for a bit... see if someone can help out...

Hope your day is well ... Have a great one..

jeremyBass

I agree with letting it sit for a while.  You might also want to ask a moderator to slip it into the WebApplications zone - you might get a fresh take on it there.  And I'm serious about asking on the CMSMS forums - if anybody has ever succeeded with this before, they may be willing to share how they did it.  Best, ~Ray

>>>>You might also want to ask a moderator to slip it into the WebApplications zone

not a bad Idea... I have to wait 24 hour before they will take the request... I wish I could now *sigh*

>>> And I'm serious about asking on the CMSMS forums
You know I normal would but I don't get much help there on things that are this deep...  in fact I do more helping then I get.. but you never know... I'll give it another go...

thanks again for the help...
Jeremy

First, Ray is totally on the ball.  Just because you want something to happen doesn't mean it can, or even that it should.  Your belief that it is not the correct answer makes it no less correct.  You are questioning the validity of his response based on "I just know it", while he has actual support for his statements.

Second, domains are separated in this manner for some very good security reasons.  Being able to access another site's cookies in any way is a bad, bad thing.  There ARE ways around it, but they are generally considered poor/malevolent practices, and should be avoided.

That said, let's break down how this works.

Option 1: multi-domain IFRAME
With this option, every page on every site loads IFRAME elements that point to a place-holder on every other domain.  This place holder exists purely to provide a 'base of operations', from which PHP or JS pulls the session ID from the cookie and exposes it.  This is not a good idea for several reasons...

1. IFRAME elements are the bastard, deformed step-children of the HTML world.  You'll find many clients that just turn them off, rendering your scheme impotent from the start.
2. The IFRAME loads in the HTML layer, which is after PHP has already done its job.  This means PHP will not be aware of the session ID until after the page load, which is a little too late.
3. Load time increases with each IFRAME, since it does represent an additional HTTP request.  With 4 or 5 domains, you're talking about a noticeable delay.


Option 2: custom session handler
Build your own session handler that writes to a custom table.  The same table serves all domains, and each domain is apportioned one column of the table.  When a session is created, that column is filled in, and indexed by the IP.  As more domains are visited, you build a collection of all session IDs associated with that IP.  This will not work because:

1. IPs can change.  Usually not between consecutive calls to a site, but it happens.
2. This will absolutely, 100% not work for proxy-based connections
3. This does not create a session hijack opportunity so much as open your server to hijackers, set up an amusement park with free food, and advertise on Craigslist that you'd like to host the largest black-hat venue ever.  A little extreme, perhaps, but you get the idea.


Option 3: custom session handler, v2 (Ray:#23290689)
Create your own, proprietary session token, and pass it around.  This supplements the automated session token created/assigned by PHP, and acts as an index to relate the different domains' tokens with each other.  Problems...?

1. The token must necessarily be transmitted to the other site by HTTP request (either POST or GET).  That exposes the token to eavesdroppers...refer to previous (Option 2, problem 3).
2. Large undertaking with tons of new code to keep your clients safe.


Option 4: redesign (Ray:#23290689)
Redesign away from differing TLDs and work with sub-domains, as the system was intended to be used in the first place.  There's a reason why x.y is considered a unique entity.  There's also ample opportunity for you to work with an x.y.z/w.y.z framework instead.

1. MASSIVE redesign.  This is always the end result when you do something horribly wrong at the start and ignore it until you can't.


Option 5: custom session handler v3
Design a custom session handler that, on first use, immediately uses curl to establish proxy session with all your other domains and populate the same indexed table.

1. You are signing the user up for a session they may or may not want.  This tends to violate 'informed consent' standards, and may constitute violations of your local laws.  Getting sued = not fun.
2. Still depends on assignment-by-IP, which breaks proxy-based clients.
3. Requires either the IFRAME strategy to set the remote cookie (in which case, why use the proxy session at all?), or requires forcing the session ID to the stored value on first visit to a new domain.  
4. It's a hijack party.


Those are pretty much all the ideas, and variations of ideas I could come up with at the moment.  I've visited this particular topic in the past for my own curiosities, and the result is much the same: it is *SO* much easier, not to mention safer, to do it the 'proper' way, even considering the work involved in a redesign.  In the course of my career, I have consistently found that not correcting a problem the instant it is identified is a sure way to collect more problems.

Good luck!

>>>>First, Ray is totally on the ball.  Just because you want something to happen doesn't mean it can, or even that it should.  Your belief that it is not the correct answer makes it no less correct.  You are questioning the validity of his response based on "I just know it", while he has actual support for his statements.


I'm sorry if it was take that I didn't believe what he was saying.. It was that I still at this point think that there may be a way... and I want to beat it down... just so I know... :-)

After reading all the options so far.. I still see one more way I think that ?? it could work???

Remember this is a test... and I'm experimenting with how before I really do the bigger real site... so thats why I don't have to do a redesign or anything so I'm ok "failing" on this one... if I've worked all the angles and nothing then I just won't do it... and I'll really know why not... :-)

So this is the thing that I think has not been shot down yet and I'm still unclear why it would not work... if it's the value of the session that defines a user... what if I store the session in the db so as I track the user moving to and from one of the domains I can pass the value instead of auto generating a new value as it does now...

no this is the thing.. CMSMS tracks logged in users...
with table cms_module_feusers_loggedin

with rows
sessionid
lastused
userid

to ?? I should be able to identify the use by knowing where there are and since this all the same script and db.. I can internally pass the value instead of auto generating a new one as I track them to the new domain I set??

That is were I'm un clear on why that would not be safe or doable... as it's all on the server side, and the user already has the value... plus there would be no post right?  And the point is now ot if it can be done... but how to do it safely.. ?yes?

Again I'm  just trying to beat it down and understand...  

One note for CMSMS is that it uses the php Smarty framework& if that helps in anyway..

Anyways.. thank you for helping& Since Im teaching my self I have to try it to understand it&

Jeremy

Oh one more idea.. log the use out and log them back in???  same db... same server... ??? would be safe?? and as far as  
>>>session they may or may not want

that would /could be stated in the privacy statement, and/or terms of sign up???

just brain storming....

I'm glad to hear this is not on a production site.  That saves you from the nightmare of redesigning an in-use app.

>>> if it's the value of the session that defines a user

Yes, and no.  The value of session defines a user in the context of the domain that set the session.  Since no two domains can be aware of the other sessions, how would you tie the two together?

You're at site A, and set a session ID of '1A'.  That gets stored in a database.  Now you go to site B, and that sets a session ID of '1B'.  Yes, the database has both session IDs, but it is not aware that they represent the same user.  In order to generate that awareness, you have to generate a communication from one site to the other.  

Now you could go to site A, get the session ID of '1A', and forcibly pass it with the user to site B.  But there's no guarantees that another user did not go site B *first*, and already owns the '1A' session ID.  If you force user 1 to pass that session ID to site B, you've just hijacked user2's session and gave it to user1.  Even in the simplest of circumstances, very not cool.  In the worst circumstances, you just handed someone's private information to a complete stranger.

Say you decide to do it with IFRAME elements.  So you generate a session of site A, and IFRAME it over to sites B, C, and D.  An attacker comes in, identifies the IFRAME trigger, and forces it to run with *their* replacement ID for site A.  They could effectively hijack all three of the secondary sessions (sites B, C, and D) from an attack originating on site A.

One misconception you have is that this is all server-side.  Granted, the heavy lifting is done there, but sessions are the link that tie a user to a server, so they are necessarily on both sides.  You cannot depend on the security of just a session ID because that ID can be compromised at any point after it leaves your server; you cannot guarantee the security model outside of your box.  Sessions != security, and that was never the intention behind them.  The only other unique you have to identify a user is their IP.  But, since that comes from a public HTTP header, which is editable, and changeable through a variety of circumstances, you cannot trust it to positively identify a remote user.  Realistically, the only way to identify a user is to generate a unique key for that user, and have them use it each time they want to be identified.  That key is normally called credentials.

So, we're back at option 3, with some edits.  Actually, a combination of option 3, option 5, plus some mandatory user interaction.  You create your own IDs (username/password), and use them to authenticate a user.  When the user goes to the next site, they have to authenticate again.  In the back-end, the authentication is related to each session ID from each site.  The main difference here is that you are not sending any session IDs anywhere, and the user login is providing both authentication and the 'tie that binds', so to speak.  The session ID is merely the way to identify the credentials supplied by the user in the context of the site.  The authentication would necessarily be done under an SSL environment to protect the credentials.

All of this leads us back to the same place: it cannot be done with sessions.  You can use sessions within the context of a single site, but in order to 'share' sessions across multiple sites, you'll need your own mechanism.

With that final paragraph, there is an important thing to remember as well: the session ID is the weak link in this model.  Once a user is authenticated, that session ID essentially becomes their security token.  When going through the log in procedure, you should be in an SSL environment before the session ID is ever generated (or, at least regenerate the session ID in an SSL environment after the authentication process ends), and force SSL cookies to boot.  If you send that sessionID across the wire without protection, and retain it through authentication, you may as well not have a login at all.  I bypass this problem by mandating SSL at the site level.  It's a little extra overhead, but you remove the headache of having to worry about when it should be in SSL or not.  You know the communications are protected from page 1.

Ok... few thing I want to clear up for me...

>>>The value of session defines a user in the context of the domain that set the session.  Since no two domains can be aware of the other sessions, how would you tie the two together?

so... hypathaticly what if site one has
name CMSSESSID7f4680cc...
value 4hudhi029c24kkjjn31d78t810
and site two has the same...

would the script think it was the same?

or because the it's come from site one ... site two would think it's a different user?

Luckly if i can find a way (I'm always hopeful).... I do the same... my important sites are ssl of the bat as well ...

No, it wouldn't.  The session ID as passed to the client is a cookie, which means it is explicitly tied to the domain that set it.  Site two will have no idea if site one has set a cookie or not because the client will never tell it.  It violates security principles if it exposes a site's cookies to anyone but that site.

Try it, and you'll see.  Each site will generate its own session ID, and you'll be able to find it on your client by searching for cookies from that domain.

I may have misunderstand there... but I meant... if both cookies were the same and the only dif was the domain...  if it was the same value would the user be thought of as the same as far as the server side went... or are you saying that even if both had the same name and value, because the domain is different the server would think it's two users?

Sorry if this is basic but Im trying to discern the line of distinction of a user so I understand...

>>> or are you saying that even if both had the same name and value, because the domain is different the server would think it's two users?

Almost.  The server would think it is two different sessions, one for each domain.  You have to remember that server does not consider sessions to be a global cache.  A session is an object *within* a domain.

Think of this in the context of phone numbers.  If I'm in Florida, and you're in California, we can both have the phone number 258-2582, but we'll have different area codes.  Yes, same exchange, same number, but completely different because we're in different states.  It is the same thing with cookies, except that the states are domains.

                    server
                    /    \
         domain1---/      \---domain2
        /   |   \            /   |   \
   sess1  sess2  sess3  sess1  sess2  sess3

Select allOpen in new window

Ok that makes more sense now... but because I'm stubborn... and really really want to achieve this effect that the user is moving from domain to domain with out logging in .. but in a safe manor... would it be possible to log the user out... and back in if I used the basic tracking ability I have?

meaning that the user is on page1 of domain1 clicks a link to page1 of domain2 but since I see that is happening I, on the back end log the user out of domain1 and relog them in domain2 ... I was thinking it'd be as if they logged them selves out and then logged on the next domain... and Id just document that fact in the privacy statement&?

I'm brainstorming .... thou I may be grasping at straws I still want to see this thought experiment out to the end...


I want to say thank you for sticking with me... you're being clear and it's helpful...

That's fine in theory, but there is no way to associate domain2 to domain1 without using some kind of communication between them.  That communication must necessarily involve the user, since they need to be aware of the changes.  The only way to do that would be to direct the user to a page that uses an IFRAME to load resources from both domains.  Those resources could then collaborate on the client machine and sort things out.  Without that interconnect, there's no way to force the session on domain2, or even associate it with domain1.

As Ray pointed out earlier this becomes a lot easier when you use sub-domains instead of TLDs.  You can share cookies between sub-domains, which means you have that built-in connection already.

>>>>but there is no way to associate domain2 to domain1 without using some kind of communication between them

see that's what I was not understanding... I have the domains talking to each other... and I was thinking of it in this mind set... like you said the user is needed to talk with the server to obtain the session... and that is what I was wanting to leverage...

I have one more question  so I have gone over everything and I'm crystal clear... can a page does a use have a session id from domain1 if they are on domain 2...? I'm thinking no but I need to ask because well if I have something then I still need to run down that path...

also is there any cookies that can be read cross domain.. that would also give me leverage to achieve this goal, in a safe manor... I think... kinda like soft key hard key type thing... shot at that point I could also match the number of "keys" to the user to... one user get 2 another gets 3... hope that makes sense...

thanks for the help.. I am trying :-)

after this I think I'm out of ideas that don't use iframes...

You can have the domain talk to the user, and you can have the domains talk to each other, but you can't have the domains talk with each other and the user.  They can't collaborate.  The infrastructure is not built that way.  An entire attack strategy (XSS) was built around that very concept.

The basics are: domain1.com can read and set domain1 cookies.  Domain2.com can read and set domain2 cookies.  That's it.  The only possible I know of to make it LOOK like domain1 is reading/setting domain2's cookies is to use IFRAMEs.  Even when two domains share the same database-driven session table, there's no way to sync the two connections.  You can associate a common login with both sessions, but that still involves either the user providing the login (MUCH preferred), or domain1 passing the provided login to domain2 (bad idea).

@routinet: Thanks for helping out here.  Regarding this: "The session ID as passed to the client is a cookie, which means it is explicitly tied to the domain that set it..." - I've found that is sort-of true.

In some installations the session is passed to the client in the URL.  This is somewhat insecure.  Consider the poor fellow who uses the computer at the public library.  He forgets to log out, and when he walks away from the keyboard, the next person in line starts to type "www" into the address bar, and the browser auto-completes the URL.  If the server garbage collection has not eliminated his session, there is a risk.  And there is another annoying thing about the session_id in the URL - if session_auto_start gets enabled and Google picks up the URLs, you now have unusable links cached in Google.

@jeremy: Required reading here: http://us2.php.net/manual/en/book.session.php and you might also want to read the Netscape Cookie specifications.

Best of luck, ~Ray

One other thought, going back to this # 23290753 about transferring the TLD in the URL.  If CMSMS rewrites your URLs, both that suggestion and any other suggestion about carrying a token or session id in the URL are at risk.

Over and out, ~Ray

@Ray,

>>> In some installations the session is passed to the client in the URL.  This is somewhat insecure.

I don't consider that a valid cookie-handling strategy in my apps, so I'm used to not even considering it as an option.  What you say is all too true, and it is unbelievably simple to hijack a URL-based session.  I believe that started out of convenience at the expense of security, and is probably the worst idea since "no, we don't need to authenticate email servers".

@Ray_Paseur: I am reading thru those... I haven't had to dive in this deep befor so I just went through the basics how to& not why... but your right this is something that needs good reading...

@both... I still have a few  more ideas.... they are all long and complicated... but should work under the conditions set by the two of you...

1.)URL based sessions are a danger
2.)the session cookie flow is server-domain-client/browser
3.)it is not possible at all for the client/browser to read session stored that are from another domain
4.)Iframes can be hijacked

So thou I'm going to write the ideas out under these conditions... they are based on this...what I want to do can be done& BUT  each separate way to achieve it has it's drawbacks or holes... reasons why it's not safe to do... so... do what's been done for 100k years before us... homogenize.

Hope that made sense... I have read through a good chuck of the smartys, CMSMS, and php forums/handbooks... and still have more to go ... but this seems possible in a responsible way... It'll take a bit to get it right... a lot of weaving... but I still have hope.. in "keys"  it's my way of thinking about it... the sessions and all the tricks are the bumps and the whole is the key.. knock a piece out and your logged out... Like you two point out... security first...  

I'll be back later.. I want to form my thoughts better so I can present them clearly... and not shot from the hip&

I want to thank you two for all the help... and for being concerned for each other two as I am in an area the could screw me... nice to see...

Be back in a bit&
Jeremy

..... interesting thought on the email... I wouldn't be in favor of any more government control over the internet.. but would agree that it'd be nice to lose spam... I may-be in favor of a law to punish spammers for steeling time from a company/or resources... a fine of a $1000 would be enough to spot most... but not on how to configure you equiment as there are laws to punish bussiness for the mistake anyway... IMHO

:-)

>>>Your main obstacle is to think ahead of the curve and resolve potential problems

yeah... I hear you on that...

>>>But...I still don't have an account with them

that's why I'm here... to work out a way that the ones that know what to look out for,  are comfortable with the solution... I want to be safe... :-)

I more then most, (google Jeremy Bass dead man) ;-)

ok... So I have thought it out and this is the trick I think may work the best... lets see what ya think here...

so pass a session that is generated based on a hashed value of the of the two last locations of the user.  but since passing that throught the post can be hijacked, that is used like a proof of address.  I'm going to think of this like getting a drivers license.  Now I can log the user out and in on the back side, so the user is only logged in to one domain at a time.  So the script would say, ok I see that you are moving from domain1  to domain2, and the client say here is my history session (the hash of the last 2 urls).  At this point the server checks it to the and if it matches the path of the user being tracked then the user is loged in and out from the first domain to the secound...

I'm trying to triangulate the user I guess... this way I can skip the IP/Iframe solutions... so a combo of Option 3 and the power of the selective domain content retrively of my settup along with the server side user tracking...

Let me know what you think... if you see a hole in there that I could/should improve on.


thank you for the help...

>>> and the client say here is my history session (the hash of the last 2 urls).

But how would the client do that?  

It's a good system overall.  There is a chance for collision, though...you'll have to decide if that chance is acceptable.  For example, if two different users each go to the home page, to the login page, then back to the home page, they'll have the same hash.

The larger problem is how to pass that hash from the client to the second domain.  If you send the hash from domain1, it will be stored as a cookie for domain1.  Domain2 will never be able to see it.

I have to put this on hold for a few days before I get back.. sorry about that... things came up... aways...  thank you two for the help...

bbl
jeremy

Thank for the pointers.... thou I got it to go ... it'd be no use to post here as it's compleletly backend on CMSMS... cheers