Two servers on the same host

[Kirill Zaborsky]

We have 2 yesod servers on the same host working on different ports, one of them is admin interface.

It happens that sessionName in yesod is set to "_SESSION" and because cookie name is the same for both servers I get session conflict (i.e. if I login to public interface I get logged out from admin interface and vice versa).

Is there any way to get 2 yesod servers on the same host without conficting one with another?

Kind regards,

Kirill Zaborsky.

[Michael Snoyman]

Three ideas come to mind:

1. You can set the cookie as being bound to a specific port, but not
all browsers respect this.
2. You could set up virtual hosting and serve each app from a
different virtual host.
3. We can have _SESSION be configurable. I think the most obvious
approach to this would be to offer an alternative to
`clientSessionBackend` that takes a parameter for the cookie name.

I'm guessing you're looking for option (3). Anyone see a problem with
that approach?

Michael

[Felipe Almeida Lessa]

On Fri, Apr 6, 2012 at 11:38 AM, Michael Snoyman <mic...@snoyman.com> wrote:
> 3. We can have _SESSION be configurable. I think the most obvious
> approach to this would be to offer an alternative to
> `clientSessionBackend` that takes a parameter for the cookie name.
>
> I'm guessing you're looking for option (3). Anyone see a problem with
> that approach?

Looks good to me. =)

--
Felipe.

[Kirill Zaborsky]

Looks good

Kind regards,

Kirill Zaborsky

2012/4/6 Michael Snoyman <mic...@snoyman.com>

[Vagif Verdi]

Here's another suggestion. Make yesod chose the session cookie name in the form of _session_port

Like _session_3000

This way, there's no need for manual configuration, no need to break API.

[Patrick Hurst]

This can still break; consider the case where domain.com/y1 reverse-proxies to 1.2.3.4:3000 and domain.com/y2 reverse-proxies to 1.2.3.5:3000.

[Vagif Verdi]

That's easily avoidable by chosing different ports on different servers.

But i get your point. We can still have our cake and eat it too.

How about yesod reading cookie name from config file, and when not found, falling back to _session_port scheme ? This way for majority of users there's no added complexity, no need to maintain yet another config variable, and for rare cases that you described, we still will have a full power of configuration.

[Patrick Hurst]

Alternately, the server could generate some suffix and store it in config/ (similar to how AES keys are generated), so a cookie name would look like _session_fyh9T82.

On Friday, April 6, 2012 at 1:12 PM, Vagif Verdi wrote:

> That's easily avoidable by chosing different ports on different servers.
>
> But i get your point. We can still have our cake and eat it too.
>
> How about yesod reading cookie name from config file, and when not found, falling back to _session_port scheme ? This way for majority of users there's no added complexity, no need to maintain yet another config variable, and for rare cases that you described, we still will have a full power of configuration.
>
>
> On Friday, April 6, 2012 9:59:21 AM UTC-7, Patrick Hurst wrote:

> > This can still break; consider the case where domain.com/y1 (http://domain.com/y1) reverse-proxies to 1.2.3.4:3000 (http://1.2.3.4:3000) and domain.com/y2 (http://domain.com/y2) reverse-proxies to 1.2.3.5:3000 (http://1.2.3.5:3000).

> >
> > On Apr 6, 2012, at 12:40, Vagif Verdi <vagif...@gmail.com (mailto:vagif...@gmail.com)> wrote:
> >
> > > Here's another suggestion. Make yesod chose the session cookie name in the form of _session_port
> > >
> > > Like _session_3000
> > >
> > > This way, there's no need for manual configuration, no need to break API.
> > >
> > > On Friday, April 6, 2012 7:38:30 AM UTC-7, Michael Snoyman wrote:
> > > > Three ideas come to mind:
> > > > 1. You can set the cookie as being bound to a specific port, but not
> > > > all browsers respect this.
> > > > 2. You could set up virtual hosting and serve each app from a
> > > > different virtual host.
> > > > 3. We can have _SESSION be configurable. I think the most obvious
> > > > approach to this would be to offer an alternative to
> > > > `clientSessionBackend` that takes a parameter for the cookie name.
> > > > I'm guessing you're looking for option (3). Anyone see a problem with
> > > > that approach?
> > > > Michael

[Felipe Almeida Lessa]

I prefer the no-magic solution. This isn't a widespread problem and
we don't need to optimize it -- ao contrário, we need to optimize the
much more common use case of a single server.

Cheers,

--
Felipe.

[Michael Snoyman]

+1.

I've pushed a change for this:

https://github.com/yesodweb/yesod/commit/4ac413e419de667219c52643ad238f3195d786da

It's a minor API breakage, which was the whole point of this last
release candidate. Let me know if this solves your problem.

Michael

[Kirill Zaborsky]

Looks OK in the source code. But I'm not sure how could I try out yesod from github in cabal-dev or something like that without messing around with ~/.cabal

Any hints on this?

Kind regards,

Kirill Zaborsky

2012/4/8 Michael Snoyman <mic...@snoyman.com>

[Greg Weber]

cabal-meta is the easiest way. cabal-meta is working well for everyone
now, so I am going to change the README instructions to use that

http://www.yesodweb.com/blog/2012/04/cabal-meta

[Greg Weber]

oh, and if you are on linux use virthualenv. Otherwise there is a
--dev option for using cabal-dev cabal-meta, but it hasn't seen as
much usage yet.

[Kirill Zaborsky]

Thanks, it's quite easy to use.

And custom session name works like a charm.

Kind regards,

Kirill Zaborsky

2012/4/8 Greg Weber <gr...@gregweber.info>