Feature reguest: change themes via URL

[Owdy]

It was possible in IPB 2.x, but not anymore in 3.x. Could you restore that feature?

[Adriano Faria]

Theme = skin ?

[Adriano Faria]

You still can change, via LINK:

Where:

k = $this->member->form_hash

settingNewSkin = Skin ID

Unless you know your form_hash, you can change via URL.

[Mat Barrie]

Adriano, really now. That's his point. You can't be expected to know the member's security key at the time of posting the link.

[Adriano Faria]

Adriano, really now. That's his point. You can't be expected to know the member's security key at the time of posting the link.

Sure. That's why I said it's better to add links to change it... Anyway, IPS should change that. I agree.

[Owdy]

Theme = skin ?

Yes.

[bfarber]

The ability to change anyone's skin was reported as a CSRF exploit, so I'm afraid you won't see that functionality back. Essentially, people could make image links that did silent redirects to change your skin without your knowledge/permission. That's what the member hash protects against, and is why it was added to the "change skin" url. So no one can change your skin without you actually doing it yourself.

[Owdy]

Then do it like SMF, if you change theme via url, it lasts only that session. Browser reboot resets it back to users default

Like this:

http://nakokulma.net/index.php?theme=35
http://nakokulma.net/index.php?theme=34

[bfarber]

But....your skin still changes. That doesn't change the "exploit", only how long the user will be affected by the exploit.


Take the lowest common denominator here. Someone's grandmother who only ever signs online to read some posts on her favorite scrapbooking forum. She logs in, visits a thread she thinks will be interesting, and suddenly the layout is drastically different, the colors are different, the background is black instead of green, the text is white instead of red. She'd be thoroughly confused and have no idea what is going on. All because someone forced her skin to change without her involvement. While tame, it's a valid "exploit" we have to protect against, and so we are.

[Owdy]

Thats bit long shot, i dont see this as "exploit" :D Someone's grandmother could accitendly change skin via that dropdown also, or grandaddy could do that when he uses same computer

[Morrigan]

I think that this isn't necessary, personally. If someone wants a new skin then they can pick one in the footer. It should be up to the user, not a URL.

[Owdy]

Well, i would like to put up mobile icon in header what leads to mobile theme. Cant do that with dropdown.

[bfarber]

Yes you can, you just have to add the variable in the URL.

<a href='http://mysite.com/index.php?setskin=1&etc.&k={$this->member->form_hash}'>Change to mobile</a>

Why can't you put a link in your header exactly?

[Owdy]

THANKS!!! :)

[Owdy]

Yes you can, you just have to add the variable in the URL.

<a href='http://mysite.com/index.php?setskin=1&etc.&k={$this->member->form_hash}'>Change to mobile</a>

Is that session only or permanent change?

[Mat Barrie]

That's permanent, Owdy. Setskin changes the member's skin choice itself.

[.Ian]

This is a shame as it would enable a skin to be viewed (by designers etc.) - I would have thought that if it was a risk then other forum software such as UBB and SMF would not allow it.

[Wolfie]

The ability to change anyone's skin was reported as a CSRF exploit, so I'm afraid you won't see that functionality back. Essentially, people could make image links that did silent redirects to change your skin without your knowledge/permission. That's what the member hash protects against, and is why it was added to the "change skin" url. So no one can change your skin without you actually doing it yourself.

What if something is done so that if a skin change is done without the session key, it will prompt the user if they want to change the skin or not (at least if they have a session key to compare with).

[Peter F.]

What if something is done so that if a skin change is done without the session key, it will prompt the user if they want to change the skin or not (at least if they have a session key to compare with).

This I believe would be an ideal solution as it would allow the "best of both" worlds so to speak. Particularly given that 3.1 now has a fully extensible notifications system.

[Donkerrood]

I would also say that it is a useful feature.

Now in 3.0.5, I have a problem with user-agent detection for guests visiting the site with a mobile device.

I do not want a guest to be able to change the skin-choice for all guests to the mobile skin (as there are less ads on the mobile skin than on the main skin).

Therefore, I have not enabled the mobile skin for the 'guest' group, so the user-agent detected mobile skin is only shown to logged in users.

I'm not sure if I made myself completely clear, but I would like to be able to change the skin either by url or somehow by using a sub-url, such as http://mobile.yourwebsite.com/

Thanks!

[Mark]

See the URL mapping section here: http://community.invisionpower.com/resources/official.html?record=162

[Matt]

Try this attached file.

Put it in your root forum directory and then when you want to link directly to a skin, use:

yoursite.com/forum/skinchange.php?id=X (where X, the skin ID).

This will of course override the CRSF protection, but you have the option. I'll add this into the 'tools' folder in 3.1.

[Owdy]

Awesome, thanks!

[Donkerrood]

See the URL mapping section here: http://community.invisionpower.com/resources/official.html?record=162

That's a good thing to know, but still, this doesn't overrule that a guest would not be allowed to see such skin...

[Mat Barrie]

That's a good thing to know, but still, this doesn't overrule that a guest would not be allowed to see such skin...

Then don't set Guests able to use the skin. You're contradicting yourself here, you want guests using mobile devices to be able to use the skin but you don't want guests able to use the skin. You want to do it by URL but don't want to do it by URL mapping.

I know IPS is good, but they haven't mastered Quantum Theory yet.