Wow, thank you for what is an extremely comprehensive answer to my enquiry and something I will have to put some time into understanding.
Just for everyone's information I am opening up my iSellit e-commerce solution as a public system. Previously we would be contracted by a company to develop a custom version of iSellit specifically to the companies needs, and would charge (like wounded bulls) to do so. What we've done instead is build a more global and multi-headed system that can be utilised by anyone. Set up is by going to the home page and specifying a 'virtual directory'. From then on an individuals shop appears as [virtdom].isellit.com.au. The shop holder can add products and customise the site to their specifications, and collect and manually process orders (PayPal will be an option too). I have solved the issue of administration login by asking for the virtual domain as part of the login procedure, and changing the login form action to the URL of the virtual domain before processing and setting variables. That way all the virtdom vars are native to the specific virtdom. Wayne Irvine On 08/11/2011, at 1:38 AM, Robert Shubert wrote: > Wayne, > > Let me start by saying that variable scoping comes down to a matter of > keying. Meaning that each scope is defined by its key, and your question is > really one of managing keys. > > First, the user scope. Technically speaking, the user scope is not restricted > to a domain. It is keyed to a session cookie which is automatically setup by > the server. Web browsers will only send session cookies back to the domain > from which they were set, and by domain, I mean http://{everything_in_here}/ > > It would be theoretically possible to set cookies which would apply to > sub-domains (eg. *.domain.com) but this is not currently a function of the > server. If there is some demand for this ability, I'll consider adding it. > > One additional note on this topic, the default setting is to key the user > scope to the cookie value alone, however it's not a bad idea to enforce the > user <-> domain connection in many cases, and to do so, the user scope key > would become: <@DOMAIN><@USERREFERENCE> > > Second, domain scopes. Domain scopes are actually keyed to the "TeraScript > Domain". However, since these are rarely setup, the default is the host and > domain portion of the URL: http://{everything_in_here}/. You can use the > domains.ini file to set up the server so that both hosts are considered the > same domain. The domains.ini would look like this: > > [Domains] > Mydomain_com_au= > > [Mydomain_com_au] > www.mydomain.com.au > abc123.mydomain.com.au > > With that in place, you could assign domain$myVar at > http://www.mydomain.com.au and then use that variable (@@domain$myVar) at > http://abc123.mydomain.com.au. Internally TeraScript would see both URLs as > being at the "Mydomain_com_au" TeraScript Domain. > > I realize that this doesn't solve your problem, but I thought it would be > helpful to know. > > Using the tools currently available to you, you can simulate what you need > using the custom scope. > > One thing that you need to do to make this work is have a unique identifier > for your user. Let's say your user is logged in and has user number 12345, > which is stored in the user variable user_id (@@user$user_id). You can store > data into a custom scope variable as such: > > <@ASSIGN scope="USERID@@user$user_id" name="myVar" value="myValue"> > > Now, by using @@user$user_id as part of the scope, I effectively created a > system wide scope which is keyed to this user's user_id. Note that I needed > to start the scope name with the text "USERID" because scope names must begin > with characters. This variable is available server wide, because custom > scopes are keyed to the scope name only, not the domain, cookie, or any other > value. > > Now, If you send your user to a different domain, all you need to do is > somehow pass the user_id (in the link, post argument, or have the user login > again). Once you know the user_id on the new domain, you can access the above > variable with: > > <@VAR USERID<@VAR user$user_id>$myVar> > > I hope that points you in the right direction. Let me know if you have > further questions, I'd be happy to help. > > Robert > > > > -----Original Message----- > From: Wayne Irvine [mailto:wa...@byteserve.com.au] > Sent: Sunday, November 06, 2011 10:32 PM > To: Witango-Talk@witango.com > Subject: Witango-Talk: Var across multiple domains > > An issue occurred to me over the weekend. You can have SCOPE=DOMAIN and the > values are accessible to all users, and you have SCOPE=USER, whose values are > accessible to a given user in a specific domain. > > Is there a SCOPE value that is available to a given user, but across multiple > domains? > > So if I set: > <@ASSIGN NAME=loggedin SCOPE=???? VALUE='yes'> in domain 'www.mydomain.com.au' > > the value would be accessible in domain 'abc321.mydomain.com.au'. > > Failing this, is there a way of passing values to a sub domain without using > a form and args? > > Wayne Irvine > > ---------------------------------------- > > To unsubscribe from this list, please send an email to lists...@witango.com > with "unsubscribe witango-talk" in the body. > > > > ---------------------------------------- > > To unsubscribe from this list, please send an email to lists...@witango.com > with "unsubscribe witango-talk" in the body. > ---------------------------------------- To unsubscribe from this list, please send an email to lists...@witango.com with "unsubscribe witango-talk" in the body.
