views:

46

answers:

3

I wan't developers who embed my webapp to be able to pass a param in the url like ?style=dark which will alter the css accordingly. Is there a better way to keep this setting as the user navigates than appending ?style=dark to all links?

I've considered cookies etc. but if one user is viewing two pages which embed my app with different themes then one will override the other.

I'm using Python/Django.

A: 

I'm not exactly sure, but anyway you would have to pass this variable to your site. With that I mean, that there is no difference if you add ?style=dark to your href's, or rel="dark" to your <a>'s for use with javascript. keep in mind that it's just an example

Ofcourse you can always work on that AI to predict what the user wanted at the specific moment. hehe

Tom
GET params like ?style=dark are sent to the server but the rel attribute is not, so using GET params is better, I'm just trying to avoid having to append them to all links.
Jake
With `rel`'s, I meant that javascript then sends the variable over.
Tom
A: 

I'm sure you can use a Session for this kind of thing, not? The first time the values are provided via the Querystring you add them to the Session and then retrieve them from the session in the future.

Bazzz
The problem there comes if a user visits one.com which embeds my app with style=dark and then opens two.com in a new tab which uses style=light. Switching back to the tab with one.com and clicking a link in my app will change the style to light.
Jake
Add the values to the session including a "key" that is provided by the querystring. So when visiting one.com a querystring comes in to your app and the key is X so values are stored for X. Then two.com enters your app and the key is Y, so values are stored for Y, in the same session object (it's the same browser/user). Then add just this key to every link that you make, so when navigating around in the tab the querystring defines which session values to use. The key identifies the value-set in the session object. This way you can store multiple value-sets in one session object.
Bazzz
Bazzz
+1  A: 

If you neither want to use Cookies nor Sessions and do not want to embed it into URLs, the only alternatives which comes to my mind are:

First the most generic: Use a dummy domain in front. Instead of www.example.com use h**p://THEME.example.com/PATH. This even works for HTTPS if you own a wildcard SSL for *.example.com.

A second variant would be to create a Basic-Auth-Handler which uses the Theme as the username with a dummy password. The URL then can look like:

h**p://[email protected]/PATH

However I am NOT sure what happens if a user connects to the same site with two different themes in the Basic-Auth-case. Also it is somewhat tricky to make the site available for search engines if it is behind an authentication handler. This is because you MUST have an auth-handler today to circumvent the Anti-Phishing-protection in modern browsers.

Note that with both methods you can only have one parameter easily. The password does not count and there are browsers out there which do not accept a wildcard SSL cert *.example.com for PARAM1.PARAM2.example.com.

Tino
I considered using a subdomain but unfortuately I do want to use SSL and have a certificate for 10 specific subdomains, not a wildcard one.I haven't tested, but I'm fairly sure basic auth will have the same problem as sessions do. I think I'll just have to go with making sure the get params are added to all links. I'll write a Django template tag to help.
Jake
Wildcard domains are no more expensive, you can get them for less than 50$ per 2 years (unfortunately these certs do not work for Android yet). I don't want to advertise so you must find it yourself.
Tino