No prob Daan :)
Like it said, it still needs some testing before merging as is into the
code base.
If you don't care much about that security issue (the risk of a XSS attack
to get your sessionkey, for which the attacker would also need network
access to your server, which he normally wouldn't if you took minimum care
of securing it :) ), this patch restores old behavior to use cookies for
session persistence:
(just did this now and didn't test, but there should be no issues)
(you can also take a backup of cloudStack.js just in case ;) )
cat << 'EOF' > patch.file
*** ui/scripts/cloudStack.js 2015-06-01 15:41:54.986000000 +0200
--- /usr/share/cloudstack-management/webapps/client/scripts/cloudStack.js
2015-06-01 15:41:51.410000000 +0200
***************
*** 117,131 ****
}
return cookieValue;
};
! unBoxCookieValue('sessionkey');
! // if sessionkey cookie exists use this to set
g_sessionKey
! // and destroy sessionkey cookie
! if ($.cookie('sessionkey')) {
! g_sessionKey = $.cookie('sessionkey');
! $.cookie('sessionkey', null);
! } else {
! g_sessionKey = unBoxCookieValue('JSESSIONID');
! }
g_role = unBoxCookieValue('role');
g_userid = unBoxCookieValue('userid');
g_domainid = unBoxCookieValue('domainid');
--- 117,123 ----
}
return cookieValue;
};
! g_sessionKey = unBoxCookieValue('sessionkey');
g_role = unBoxCookieValue('role');
g_userid = unBoxCookieValue('userid');
g_domainid = unBoxCookieValue('domainid');
***************
*** 234,239 ****
--- 226,234 ----
g_timezone = loginresponse.timezone;
g_userfullname = loginresponse.firstname + ' ' +
loginresponse.lastname;
+ $.cookie('sessionKey', g_sessionKey, {
+ expires: 1
+ });
$.cookie('username', g_username, {
expires: 1
});
EOF
patch /usr/share/cloudstack-management/webapps/client/scripts/cloudStack.js
-i patch.file
On Mon, Jun 1, 2015 at 3:41 PM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:
> Andrija, Rafael, I took a few minutes to look at it. It doesn't apply even
> after some simple tinkering. Hope you will once forgive me for not taking
> this in the next RC. baking it now
>
> Op ma 1 jun. 2015 om 15:22 schreef Andrija Panic <andrija.pa...@gmail.com
> >:
>
> > :) please do - send the patch.
> >
> > Thanks Rafael
> >
> > On 1 June 2015 at 15:16, Rafael Fonseca <rsafons...@gmail.com> wrote:
> >
> > > Hi Andrija,
> > >
> > > The first fix i had proposed might not have been a problem, besides the
> > > security issue.
> > > I have now updated the PR to fix the security issue, but tests for
> other
> > > authentication methods must be performed before a merge.
> > > I think Rohit is looking into testing the SAML plugin with it, if it's
> > ok i
> > > guess it can be merged, if not, it will still have to be made
> compatible
> > > with those auth plugins.
> > > If you'd like i can give you a small patch to fix session management in
> > > your environment, you can patch in place after installation, so easy to
> > do
> > > :)
> > >
> > >
> > >
> > > On Mon, Jun 1, 2015 at 2:34 PM, Andrija Panic <andrija.pa...@gmail.com
> >
> > > wrote:
> > >
> > > > Daan, Rafael,
> > > >
> > > > what about Rafael's https://github.com/apache/cloudstack/pull/308 -
> it
> > > > need
> > > > to be reviewsed by security time - fine, but can we merge this, and
> > undo
> > > > alter, if necessary ?
> > > >
> > > > On 1 June 2015 at 14:26, Rafael Fonseca <rsafons...@gmail.com>
> wrote:
> > > >
> > > > > Hey Daan,
> > > > > I've also created a PR for fixing a couple of deb packaging issues
> > for
> > > > 4.4
> > > > > Have a look here:
> > > > > https://github.com/apache/cloudstack/pull/339
> > > > >
> > > > >
> > > > > On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber <terbol...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Sounds reasonable to me.
> > > > > >
> > > > > > --
> > > > > > Erik
> > > > > >
> > > > > > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland <
> > > daan.hoogl...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > If no objections I will reset the default to 4.4.1 (the lowest
> > > > required
> > > > > > > version) include Rafaels pr for kvm/centos packaging and
> create a
> > > new
> > > > > rc.
> > > > > > >
> > > > > > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > > > > > daan.hoogl...@gmail.com
> > > > > > > >:
> > > > > > >
> > > > > > > > So we will have to include an update in every release and we
> > will
> > > > > > > probably
> > > > > > > > forget about that pretty soon.
> > > > > > > >
> > > > > > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma <
> r...@remi.nl
> > >:
> > > > > > > >
> > > > > > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x
> > release,
> > > > and
> > > > > > > 4.5.0
> > > > > > > >> for 4.5.x etc. This is also close to what was hard-coded
> > before.
> > > > > > > >>
> > > > > > > >> Regards,
> > > > > > > >> Remi
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <
> > > daan.hoogl...@gmail.com
> > > > >:
> > > > > > > >>
> > > > > > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for
> > my
> > > > > part,
> > > > > > it
> > > > > > > >> must
> > > > > > > >> > be an operator decision to set the MinVRVersion if it must
> > be
> > > > > > higher.
> > > > > > > It
> > > > > > > >> > will always be an upgrade matter and any seeded template
> > > should
> > > > be
> > > > > > > >> accepted
> > > > > > > >> > as per the installation notes. Of course the other side of
> > the
> > > > > issue
> > > > > > > is
> > > > > > > >> > whether a version will work at all. The operator can
> create
> > a
> > > > > > version
> > > > > > > of
> > > > > > > >> > the template with their own versioning scheme, however. I
> > > should
> > > > > be
> > > > > > > >> writing
> > > > > > > >> > all this in another {DISCUSS]-thread.
> > > > > > > >> >
> > > > > > > >> > cancelling the RC to add code for Bruno's requirement.
> > > > > > > >> >
> > > > > > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <
> > > > milam...@apache.org
> > > > > >:
> > > > > > > >> >
> > > > > > > >> > >
> > > > > > > >> > > Please note: I my case, there isn't an upgrade, I have
> the
> > > > issue
> > > > > > > with
> > > > > > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from
> > git
> > > > tag
> > > > > > > >> > > 4.4-RC20150529T2004)
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > > > > > >> > > > If it means that all upgrades are unable to do VR
> > related
> > > > > tasks
> > > > > > (
> > > > > > > >> > > starting
> > > > > > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > > > > > >> > > > Relying on all our users to do manual fixing just
> > because
> > > we
> > > > > > don't
> > > > > > > >> want
> > > > > > > >> > > to
> > > > > > > >> > > > call off the RC is bad IMHO.
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Andrija Panić
> > > >
> > >
> >
> >
> >
> > --
> >
> > Andrija Panić
> >
>
