We "Jfusion" have a option to redirect after login. how would i be able to preform a costum redirect ?? The problem with the redirect is that since it happens in onUserLogin and the remember me cookie is set AFTER this.
This means the remember me cookie is never set.
The problem is we cant use built in redirect because it only allow some url's we need redirect option to be able to do to any site, even 3rd party url's (as well as other sides) EG "SSL"
What i dont understand, or maybe miss stand is .. why do the remember me need the results from onUserLogin/onLoginUser when the user has already passed Authentication
should the remember me cookie not be set in between auth and onUserLogin/onLoginUse ? I guess i can see a reason why not. In any case i suspect this is not a "bug", but a "api" limitation pehaps we cant add the redirect some other way a: // Trigger onUserLoginSucess Event. $this->triggerEvent('onUserLoginSucess', array((array) $response));
perhaps add AFTER the remember me creation so that a redirect could be executed there? I know tho that this would not solve out current "issue"
-Thanks Morten
P.S. I am open to any suggestion's you might have. Dev on the JFusion project
An argument could be made that the remember me cookie code should
probably live in the Joomla! user plugin however in arguing where
things live login itself probably isn't best suited to the application
in general (there are apps that don't require login for example).
However I'm mildly confused because the login controller in com_user
already supports redirecting the user in 2.5, why not just change that
param?
Perhaps I'm not sure what the problem is, just set the return to be
where you want it to be. I just created a reasonably complicated URL
example to prove the point. It has SSL, is reasonably complicated (in
my mind anyway) and is an external site. Joomla! after login appears
quite happy to send the user there.
This example I wrote against 2.5, it won't work in 1.5 because the
extension is different. I'd argue the 2.5 behaviour is the best
because you can reset it from a plugin, you're not breaking your scope
(plugins randomly terminating application execution is something we
need to avoid) and it appears to be reasonably flexible unless I'm
missing something.
<?php
jimport('joomla.plugin.plugin');
class plgUserTest extends JPlugin
{
public function onUserLogin()
{
On Wed, Jul 4, 2012 at 11:53 AM, fanno <fan...@gmail.com> wrote:
> Hi all
> We "Jfusion" have a option to redirect after login. how would i be able to
> preform a costum redirect ?? The problem with the redirect is that since it
> happens in onUserLogin and the remember me cookie is set AFTER this.
> This means the remember me cookie is never set.
> The problem is we cant use built in redirect because it only allow some
> url's we need redirect option to be able to do to any site, even 3rd party
> url's (as well as other sides) EG "SSL"
> What i dont understand, or maybe miss stand is .. why do the remember me
> need the results from onUserLogin/onLoginUser when the user has already
> passed Authentication
> should the remember me cookie not be set in between auth and
> onUserLogin/onLoginUse ? I guess i can see a reason why not. In any case i
> suspect this is not a "bug", but a "api" limitation pehaps we cant add the
> redirect some other way a:
> // Trigger onUserLoginSucess Event.
> $this->triggerEvent('onUserLoginSucess', array((array) $response));
> perhaps add AFTER the remember me creation so that a redirect could be
> executed there? I know tho that this would not solve out current "issue"
> -Thanks
> Morten
> P.S.
> I am open to any suggestion's you might have.
> Dev on the JFusion project
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! bug Squad" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/joomlabugsquad/-/90hbEmhW-RAJ.
> To post to this group, send email to joomlabugsquad@googlegroups.com.
> To unsubscribe from this group, send email to
> joomlabugsquad+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomlabugsquad?hl=en.
> We "Jfusion" have a option to redirect after login. how would i be able to > preform a costum redirect ?? The problem with the redirect is that since it > happens in onUserLogin and the remember me cookie is set AFTER this.
> This means the remember me cookie is never set.
> The problem is we cant use built in redirect because it only allow some > url's we need redirect option to be able to do to any site, even 3rd party > url's (as well as other sides) EG "SSL"
> What i dont understand, or maybe miss stand is .. why do the remember me > need the results from onUserLogin/onLoginUser when the user has already > passed Authentication
> should the remember me cookie not be set in between auth > and onUserLogin/onLoginUse ? I guess i can see a reason why not. In any > case i suspect this is not a "bug", but a "api" limitation pehaps we cant > add the redirect some other way a: > // Trigger onUserLoginSucess Event. > $this->triggerEvent('onUserLoginSucess', array((array) $response));
> perhaps add AFTER the remember me creation so that a redirect could be > executed there? I know tho that this would not solve out current "issue"
> -Thanks > Morten
> P.S. > I am open to any suggestion's you might have. > Dev on the JFusion project
> out redirect need to happen to allow cross domain cookies to be set. tho > it may still need a tweek here and there.
> -Thanks for your input Samuel
> Den onsdag den 4. juli 2012 20.53.18 UTC+2 skrev fanno:
>> Hi all
>> We "Jfusion" have a option to redirect after login. how would i be able >> to preform a costum redirect ?? The problem with the redirect is that since >> it happens in onUserLogin and the remember me cookie is set AFTER this.
>> This means the remember me cookie is never set.
>> The problem is we cant use built in redirect because it only allow some >> url's we need redirect option to be able to do to any site, even 3rd party >> url's (as well as other sides) EG "SSL"
>> What i dont understand, or maybe miss stand is .. why do the remember me >> need the results from onUserLogin/onLoginUser when the user has already >> passed Authentication
>> should the remember me cookie not be set in between auth >> and onUserLogin/onLoginUse ? I guess i can see a reason why not. In any >> case i suspect this is not a "bug", but a "api" limitation pehaps we cant >> add the redirect some other way a: >> // Trigger onUserLoginSucess Event. >> $this->triggerEvent('onUserLoginSucess', array((array) $response));
>> perhaps add AFTER the remember me creation so that a redirect could be >> executed there? I know tho that this would not solve out current "issue"
>> -Thanks >> Morten
>> P.S. >> I am open to any suggestion's you might have. >> Dev on the JFusion project
Submit a patch to bring logout in line with login then and then
problem solved moving forwards. Alternatively you can detect a logout
with a system plugin and rewrite the request to go through your
extension and have any logic you need in there.
>> out redirect need to happen to allow cross domain cookies to be set. tho
>> it may still need a tweek here and there.
>> -Thanks for your input Samuel
>> Den onsdag den 4. juli 2012 20.53.18 UTC+2 skrev fanno:
>>> Hi all
>>> We "Jfusion" have a option to redirect after login. how would i be able
>>> to preform a costum redirect ?? The problem with the redirect is that since
>>> it happens in onUserLogin and the remember me cookie is set AFTER this.
>>> This means the remember me cookie is never set.
>>> The problem is we cant use built in redirect because it only allow some
>>> url's we need redirect option to be able to do to any site, even 3rd party
>>> url's (as well as other sides) EG "SSL"
>>> What i dont understand, or maybe miss stand is .. why do the remember me
>>> need the results from onUserLogin/onLoginUser when the user has already
>>> passed Authentication
>>> should the remember me cookie not be set in between auth and
>>> onUserLogin/onLoginUse ? I guess i can see a reason why not. In any case i
>>> suspect this is not a "bug", but a "api" limitation pehaps we cant add the
>>> redirect some other way a:
>>> // Trigger onUserLoginSucess Event.
>>> $this->triggerEvent('onUserLoginSucess', array((array) $response));
>>> perhaps add AFTER the remember me creation so that a redirect could be
>>> executed there? I know tho that this would not solve out current "issue"
>>> -Thanks
>>> Morten
>>> P.S.
>>> I am open to any suggestion's you might have.
>>> Dev on the JFusion project
> To post to this group, send email to joomlabugsquad@googlegroups.com.
> To unsubscribe from this group, send email to
> joomlabugsquad+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomlabugsquad?hl=en.
> We "Jfusion" have a option to redirect after login. how would i be able to > preform a costum redirect ?? The problem with the redirect is that since it > happens in onUserLogin and the remember me cookie is set AFTER this.
> This means the remember me cookie is never set.
> The problem is we cant use built in redirect because it only allow some > url's we need redirect option to be able to do to any site, even 3rd party > url's (as well as other sides) EG "SSL"
> What i dont understand, or maybe miss stand is .. why do the remember me > need the results from onUserLogin/onLoginUser when the user has already > passed Authentication
> should the remember me cookie not be set in between auth > and onUserLogin/onLoginUse ? I guess i can see a reason why not. In any > case i suspect this is not a "bug", but a "api" limitation pehaps we cant > add the redirect some other way a: > // Trigger onUserLoginSucess Event. > $this->triggerEvent('onUserLoginSucess', array((array) $response));
> perhaps add AFTER the remember me creation so that a redirect could be > executed there? I know tho that this would not solve out current "issue"
> -Thanks > Morten
> P.S. > I am open to any suggestion's you might have. > Dev on the JFusion project
> Should, what git branch should i checkout to build the patch on ? i would > assume "master" ? 3.0 ? if i recall i read that master is now 3.0
> -Thanks
> Den onsdag den 4. juli 2012 20.53.18 UTC+2 skrev fanno:
>> Hi all
>> We "Jfusion" have a option to redirect after login. how would i be able >> to preform a costum redirect ?? The problem with the redirect is that since >> it happens in onUserLogin and the remember me cookie is set AFTER this.
>> This means the remember me cookie is never set.
>> The problem is we cant use built in redirect because it only allow some >> url's we need redirect option to be able to do to any site, even 3rd party >> url's (as well as other sides) EG "SSL"
>> What i dont understand, or maybe miss stand is .. why do the remember me >> need the results from onUserLogin/onLoginUser when the user has already >> passed Authentication
>> should the remember me cookie not be set in between auth >> and onUserLogin/onLoginUse ? I guess i can see a reason why not. In any >> case i suspect this is not a "bug", but a "api" limitation pehaps we cant >> add the redirect some other way a: >> // Trigger onUserLoginSucess Event. >> $this->triggerEvent('onUserLoginSucess', array((array) $response));
>> perhaps add AFTER the remember me creation so that a redirect could be >> executed there? I know tho that this would not solve out current "issue"
>> -Thanks >> Morten
>> P.S. >> I am open to any suggestion's you might have. >> Dev on the JFusion project
> Den torsdag den 5. juli 2012 18.46.18 UTC+2 skrev fanno:
>> Should, what git branch should i checkout to build the patch on ? i would >> assume "master" ? 3.0 ? if i recall i read that master is now 3.0
>> -Thanks
>> Den onsdag den 4. juli 2012 20.53.18 UTC+2 skrev fanno:
>>> Hi all
>>> We "Jfusion" have a option to redirect after login. how would i be able >>> to preform a costum redirect ?? The problem with the redirect is that since >>> it happens in onUserLogin and the remember me cookie is set AFTER this.
>>> This means the remember me cookie is never set.
>>> The problem is we cant use built in redirect because it only allow some >>> url's we need redirect option to be able to do to any site, even 3rd party >>> url's (as well as other sides) EG "SSL"
>>> What i dont understand, or maybe miss stand is .. why do the remember me >>> need the results from onUserLogin/onLoginUser when the user has already >>> passed Authentication
>>> should the remember me cookie not be set in between auth >>> and onUserLogin/onLoginUse ? I guess i can see a reason why not. In any >>> case i suspect this is not a "bug", but a "api" limitation pehaps we cant >>> add the redirect some other way a: >>> // Trigger onUserLoginSucess Event. >>> $this->triggerEvent('onUserLoginSucess', array((array) $response));
>>> perhaps add AFTER the remember me creation so that a redirect could be >>> executed there? I know tho that this would not solve out current "issue"
>>> -Thanks >>> Morten
>>> P.S. >>> I am open to any suggestion's you might have. >>> Dev on the JFusion project
>> Den torsdag den 5. juli 2012 18.46.18 UTC+2 skrev fanno:
>>> Should, what git branch should i checkout to build the patch on ? i would
>>> assume "master" ? 3.0 ? if i recall i read that master is now 3.0
>>> -Thanks
>>> Den onsdag den 4. juli 2012 20.53.18 UTC+2 skrev fanno:
>>>> Hi all
>>>> We "Jfusion" have a option to redirect after login. how would i be able
>>>> to preform a costum redirect ?? The problem with the redirect is that since
>>>> it happens in onUserLogin and the remember me cookie is set AFTER this.
>>>> This means the remember me cookie is never set.
>>>> The problem is we cant use built in redirect because it only allow some
>>>> url's we need redirect option to be able to do to any site, even 3rd party
>>>> url's (as well as other sides) EG "SSL"
>>>> What i dont understand, or maybe miss stand is .. why do the remember me
>>>> need the results from onUserLogin/onLoginUser when the user has already
>>>> passed Authentication
>>>> should the remember me cookie not be set in between auth and
>>>> onUserLogin/onLoginUse ? I guess i can see a reason why not. In any case i
>>>> suspect this is not a "bug", but a "api" limitation pehaps we cant add the
>>>> redirect some other way a:
>>>> // Trigger onUserLoginSucess Event.
>>>> $this->triggerEvent('onUserLoginSucess', array((array) $response));
>>>> perhaps add AFTER the remember me creation so that a redirect could be
>>>> executed there? I know tho that this would not solve out current "issue"
>>>> -Thanks
>>>> Morten
>>>> P.S.
>>>> I am open to any suggestion's you might have.
>>>> Dev on the JFusion project
> To post to this group, send email to joomlabugsquad@googlegroups.com.
> To unsubscribe from this group, send email to
> joomlabugsquad+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomlabugsquad?hl=en.
hmm i realise it is now a "development issue" but since i already have it here i hope it is on to keep going here rather than moving to joomla dev...
$app->getUserState('users.logout.form.return') cant be used as after logout has happen becuase $app->getUserState(...) pulls from session data and since session is destroyed at this point it is "tolate" to retrieve it..
This means it cant be brought in to work the same way. what other methods could be used ? that would work with both login/out ? or could something be change so that the actual kill of the session only happens after it is used? in this last location ?
i have not look deep in to it but joomla user plugin:
onUserLogout(....) { .... $session = JFactory::getSession(); ... // Destroy the php session for this user $session->destroy(); ....
}
-Thanks
Den onsdag den 4. juli 2012 20.53.18 UTC+2 skrev fanno:
> We "Jfusion" have a option to redirect after login. how would i be able to > preform a costum redirect ?? The problem with the redirect is that since it > happens in onUserLogin and the remember me cookie is set AFTER this.
> This means the remember me cookie is never set.
> The problem is we cant use built in redirect because it only allow some > url's we need redirect option to be able to do to any site, even 3rd party > url's (as well as other sides) EG "SSL"
> What i dont understand, or maybe miss stand is .. why do the remember me > need the results from onUserLogin/onLoginUser when the user has already > passed Authentication
> should the remember me cookie not be set in between auth > and onUserLogin/onLoginUse ? I guess i can see a reason why not. In any > case i suspect this is not a "bug", but a "api" limitation pehaps we cant > add the redirect some other way a: > // Trigger onUserLoginSucess Event. > $this->triggerEvent('onUserLoginSucess', array((array) $response));
> perhaps add AFTER the remember me creation so that a redirect could be > executed there? I know tho that this would not solve out current "issue"
> -Thanks > Morten
> P.S. > I am open to any suggestion's you might have. > Dev on the JFusion project
If we do some juggling we could use JRequest::setVar and a second
getVar to handle it.
e.g.
$app = JFactory::getApplication();
// Get the return url from the request and validate that it is internal.
$return = JRequest::getVar('return', '', 'method', 'base64');
$return = base64_decode($return);
if (!JURI::isInternal($return)) {
$return = '';
}
JRequest::setVar('return', $return, 'method');
// Perform the log in.
$error = $app->logout();
// Check if the log out succeeded.
if (!($error instanceof Exception)) {
The return check is shifted before logout and resets the return param
in the request. This solves any injection of the return method that
the particular chunk of code is protected against with the isInternal
check. As an aside probably not a bad idea to put that back in the
above chunk of code though I'm not sure why it was removed to begin
with. Then the logout is called where in the session is destroyed and
your plugin run. In there you can call JRequest::setVar() to reset it
and if it completes without error the user will be sent on their merry
way.
On Fri, Jul 6, 2012 at 9:07 AM, fanno <fan...@gmail.com> wrote:
> hmm i realise it is now a "development issue" but since i already have it
> here i hope it is on to keep going here rather than moving to joomla dev...
> $app->getUserState('users.logout.form.return') cant be used as after logout
> has happen becuase $app->getUserState(...) pulls from session data and since
> session is destroyed at this point it is "tolate" to retrieve it..
> This means it cant be brought in to work the same way. what other methods
> could be used ? that would work with both login/out ? or could something be
> change so that the actual kill of the session only happens after it is used?
> in this last location ?
> i have not look deep in to it but joomla user plugin:
> onUserLogout(....) {
> ....
> $session = JFactory::getSession();
> ...
> // Destroy the php session for this user
> $session->destroy();
> ....
> }
> -Thanks
> Den onsdag den 4. juli 2012 20.53.18 UTC+2 skrev fanno:
>> Hi all
>> We "Jfusion" have a option to redirect after login. how would i be able to
>> preform a costum redirect ?? The problem with the redirect is that since it
>> happens in onUserLogin and the remember me cookie is set AFTER this.
>> This means the remember me cookie is never set.
>> The problem is we cant use built in redirect because it only allow some
>> url's we need redirect option to be able to do to any site, even 3rd party
>> url's (as well as other sides) EG "SSL"
>> What i dont understand, or maybe miss stand is .. why do the remember me
>> need the results from onUserLogin/onLoginUser when the user has already
>> passed Authentication
>> should the remember me cookie not be set in between auth and
>> onUserLogin/onLoginUse ? I guess i can see a reason why not. In any case i
>> suspect this is not a "bug", but a "api" limitation pehaps we cant add the
>> redirect some other way a:
>> // Trigger onUserLoginSucess Event.
>> $this->triggerEvent('onUserLoginSucess', array((array) $response));
>> perhaps add AFTER the remember me creation so that a redirect could be
>> executed there? I know tho that this would not solve out current "issue"
>> -Thanks
>> Morten
>> P.S.
>> I am open to any suggestion's you might have.
>> Dev on the JFusion project
> To post to this group, send email to joomlabugsquad@googlegroups.com.
> To unsubscribe from this group, send email to
> joomlabugsquad+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomlabugsquad?hl=en.
would this not be better ? we as devs are used to the return value to be encoded. Changing this could bad ?
i would say keep it encoded ?
I do not know if the $return === false is really needed ? but it would check against invalid content.
$app = JFactory::getApplication();
// Get the return url from the request and validate that it is internal. $return = JRequest::getVar('return', '', 'method', 'base64'); $return = base64_decode($return); if (!JURI::isInternal($return)) { $return = ''; } JRequest::setVar('return', base64_encode($return), 'method');
// Perform the log in. $error = $app->logout();
// Check if the log out succeeded. if (!($error instanceof Exception)) { $return = JRequest::getVar('return', '', 'method');
$return = base64_decode($return); if ($return === false) {
$return = '';
> If we do some juggling we could use JRequest::setVar and a second > getVar to handle it.
> e.g. > $app = JFactory::getApplication();
> // Get the return url from the request and validate that > it is internal. > $return = JRequest::getVar('return', '', 'method', > 'base64'); > $return = base64_decode($return); > if (!JURI::isInternal($return)) { > $return = ''; > } > JRequest::setVar('return', $return, 'method');
> // Perform the log in. > $error = $app->logout();
> // Check if the log out succeeded. > if (!($error instanceof Exception)) {
> The return check is shifted before logout and resets the return param > in the request. This solves any injection of the return method that > the particular chunk of code is protected against with the isInternal > check. As an aside probably not a bad idea to put that back in the > above chunk of code though I'm not sure why it was removed to begin > with. Then the logout is called where in the session is destroyed and > your plugin run. In there you can call JRequest::setVar() to reset it > and if it completes without error the user will be sent on their merry > way.
> On Fri, Jul 6, 2012 at 9:07 AM, fanno <fan...@gmail.com> wrote: > > hmm i realise it is now a "development issue" but since i already have > it > > here i hope it is on to keep going here rather than moving to joomla > dev...
> > $app->getUserState('users.logout.form.return') cant be used as after > logout > > has happen becuase $app->getUserState(...) pulls from session data and > since > > session is destroyed at this point it is "tolate" to retrieve it..
> > This means it cant be brought in to work the same way. what other > methods > > could be used ? that would work with both login/out ? or could something > be > > change so that the actual kill of the session only happens after it is > used? > > in this last location ?
> > i have not look deep in to it but joomla user plugin:
> > onUserLogout(....) { > > .... > > $session = JFactory::getSession(); > > ... > > // Destroy the php session for this user > > $session->destroy(); > > .... > > }
> > -Thanks
> > Den onsdag den 4. juli 2012 20.53.18 UTC+2 skrev fanno:
> >> Hi all
> >> We "Jfusion" have a option to redirect after login. how would i be able > to > >> preform a costum redirect ?? The problem with the redirect is that > since it > >> happens in onUserLogin and the remember me cookie is set AFTER this.
> >> This means the remember me cookie is never set.
> >> The problem is we cant use built in redirect because it only allow some > >> url's we need redirect option to be able to do to any site, even 3rd > party > >> url's (as well as other sides) EG "SSL"
> >> What i dont understand, or maybe miss stand is .. why do the remember > me > >> need the results from onUserLogin/onLoginUser when the user has already > >> passed Authentication
> >> should the remember me cookie not be set in between auth and > >> onUserLogin/onLoginUse ? I guess i can see a reason why not. In any > case i > >> suspect this is not a "bug", but a "api" limitation pehaps we cant add > the > >> redirect some other way a: > >> // Trigger onUserLoginSucess Event. > >> $this->triggerEvent('onUserLoginSucess', array((array) $response));
> >> perhaps add AFTER the remember me creation so that a redirect could be > >> executed there? I know tho that this would not solve out current > "issue"
> >> -Thanks > >> Morten
> >> P.S. > >> I am open to any suggestion's you might have. > >> Dev on the JFusion project
> > To post to this group, send email to joomlabugsquad@googlegroups.com. > > To unsubscribe from this group, send email to > > joomlabugsquad+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/joomlabugsquad?hl=en.
Den søndag den 8. juli 2012 20.42.12 UTC+2 skrev Samuel Moffatt:
> If we do some juggling we could use JRequest::setVar and a second > getVar to handle it.
> e.g. > $app = JFactory::getApplication();
> // Get the return url from the request and validate that > it is internal. > $return = JRequest::getVar('return', '', 'method', > 'base64'); > $return = base64_decode($return); > if (!JURI::isInternal($return)) { > $return = ''; > } > JRequest::setVar('return', $return, 'method');
> // Perform the log in. > $error = $app->logout();
> // Check if the log out succeeded. > if (!($error instanceof Exception)) {
> The return check is shifted before logout and resets the return param > in the request. This solves any injection of the return method that > the particular chunk of code is protected against with the isInternal > check. As an aside probably not a bad idea to put that back in the > above chunk of code though I'm not sure why it was removed to begin > with. Then the logout is called where in the session is destroyed and > your plugin run. In there you can call JRequest::setVar() to reset it > and if it completes without error the user will be sent on their merry > way.
> On Fri, Jul 6, 2012 at 9:07 AM, fanno <fan...@gmail.com> wrote: > > hmm i realise it is now a "development issue" but since i already have > it > > here i hope it is on to keep going here rather than moving to joomla > dev...
> > $app->getUserState('users.logout.form.return') cant be used as after > logout > > has happen becuase $app->getUserState(...) pulls from session data and > since > > session is destroyed at this point it is "tolate" to retrieve it..
> > This means it cant be brought in to work the same way. what other > methods > > could be used ? that would work with both login/out ? or could something > be > > change so that the actual kill of the session only happens after it is > used? > > in this last location ?
> > i have not look deep in to it but joomla user plugin:
> > onUserLogout(....) { > > .... > > $session = JFactory::getSession(); > > ... > > // Destroy the php session for this user > > $session->destroy(); > > .... > > }
> > -Thanks
> > Den onsdag den 4. juli 2012 20.53.18 UTC+2 skrev fanno:
> >> Hi all
> >> We "Jfusion" have a option to redirect after login. how would i be able > to > >> preform a costum redirect ?? The problem with the redirect is that > since it > >> happens in onUserLogin and the remember me cookie is set AFTER this.
> >> This means the remember me cookie is never set.
> >> The problem is we cant use built in redirect because it only allow some > >> url's we need redirect option to be able to do to any site, even 3rd > party > >> url's (as well as other sides) EG "SSL"
The URL being encoded is a minor obfuscation and avoidance of URL
double encoding problems in the request however if we're in the PHP
process neither are concerns any more (we're not going to have IIS
shut down the request for the double encoding since we're inside the
request). So I was trying to avoid the needless encoding/re-encoding
however I guess for backwards compatibility we could retain it in case
anyone is relying on that behaviour to set an internal redirect. That
said given 3.0 isn't guaranteed to be backwards compatible this is
perhaps one of the areas where it makes sense to break that and just
do the right thing from 3.x onwards.
On Mon, Jul 9, 2012 at 2:42 AM, fanno <fan...@gmail.com> wrote:
> would this not be better ? we as devs are used to the return value to be
> encoded. Changing this could bad ?
> i would say keep it encoded ?
> I do not know if the $return === false is really needed ? but it would
> check against invalid content.
> $app = JFactory::getApplication();
> // Get the return url from the request and validate that it
> is internal.
> $return = JRequest::getVar('return', '', 'method',
> 'base64');
> $return = base64_decode($return);
> if (!JURI::isInternal($return)) {
> $return = '';
> }
> JRequest::setVar('return', base64_encode($return),
> 'method');
> // Perform the log in.
> $error = $app->logout();
> // Check if the log out succeeded.
> if (!($error instanceof Exception)) {
> $return = JRequest::getVar('return', '', 'method');
> $return = base64_decode($return);
> if ($return === false) {
> $return = '';
> }
> // Redirect the user.
> $app->redirect(JRoute::_($return, false));
> } else {
> Den søndag den 8. juli 2012 20.42.12 UTC+2 skrev Samuel Moffatt:
>> If we do some juggling we could use JRequest::setVar and a second
>> getVar to handle it.
>> e.g.
>> $app = JFactory::getApplication();
>> // Get the return url from the request and validate that
>> it is internal.
>> $return = JRequest::getVar('return', '', 'method',
>> 'base64');
>> $return = base64_decode($return);
>> if (!JURI::isInternal($return)) {
>> $return = '';
>> }
>> JRequest::setVar('return', $return, 'method');
>> // Perform the log in.
>> $error = $app->logout();
>> // Check if the log out succeeded.
>> if (!($error instanceof Exception)) {
>> The return check is shifted before logout and resets the return param
>> in the request. This solves any injection of the return method that
>> the particular chunk of code is protected against with the isInternal
>> check. As an aside probably not a bad idea to put that back in the
>> above chunk of code though I'm not sure why it was removed to begin
>> with. Then the logout is called where in the session is destroyed and
>> your plugin run. In there you can call JRequest::setVar() to reset it
>> and if it completes without error the user will be sent on their merry
>> way.
>> On Fri, Jul 6, 2012 at 9:07 AM, fanno <fan...@gmail.com> wrote:
>> > hmm i realise it is now a "development issue" but since i already have
>> > it
>> > here i hope it is on to keep going here rather than moving to joomla
>> > dev...
>> > $app->getUserState('users.logout.form.return') cant be used as after
>> > logout
>> > has happen becuase $app->getUserState(...) pulls from session data and
>> > since
>> > session is destroyed at this point it is "tolate" to retrieve it..
>> > This means it cant be brought in to work the same way. what other
>> > methods
>> > could be used ? that would work with both login/out ? or could something
>> > be
>> > change so that the actual kill of the session only happens after it is
>> > used?
>> > in this last location ?
>> > i have not look deep in to it but joomla user plugin:
>> > onUserLogout(....) {
>> > ....
>> > $session = JFactory::getSession();
>> > ...
>> > // Destroy the php session for this user
>> > $session->destroy();
>> > ....
>> > }
>> > -Thanks
>> > Den onsdag den 4. juli 2012 20.53.18 UTC+2 skrev fanno:
>> >> Hi all
>> >> We "Jfusion" have a option to redirect after login. how would i be able
>> >> to
>> >> preform a costum redirect ?? The problem with the redirect is that
>> >> since it
>> >> happens in onUserLogin and the remember me cookie is set AFTER this.
>> >> This means the remember me cookie is never set.
>> >> The problem is we cant use built in redirect because it only allow some
>> >> url's we need redirect option to be able to do to any site, even 3rd
>> >> party
>> >> url's (as well as other sides) EG "SSL"
>> >> What i dont understand, or maybe miss stand is .. why do the remember
>> >> me
>> >> need the results from onUserLogin/onLoginUser when the user has already
>> >> passed Authentication
>> >> should the remember me cookie not be set in between auth and
>> >> onUserLogin/onLoginUse ? I guess i can see a reason why not. In any
>> >> case i
>> >> suspect this is not a "bug", but a "api" limitation pehaps we cant add
>> >> the
>> >> redirect some other way a:
>> >> // Trigger onUserLoginSucess Event.
>> >> $this->triggerEvent('onUserLoginSucess', array((array) $response));
>> >> perhaps add AFTER the remember me creation so that a redirect could be
>> >> executed there? I know tho that this would not solve out current
>> >> "issue"
>> >> -Thanks
>> >> Morten
>> >> P.S.
>> >> I am open to any suggestion's you might have.
>> >> Dev on the JFusion project
>> > To post to this group, send email to joomlabugsquad@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > joomlabugsquad+unsubscribe@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/joomlabugsquad?hl=en.
> Den søndag den 8. juli 2012 20.42.12 UTC+2 skrev Samuel Moffatt:
>> If we do some juggling we could use JRequest::setVar and a second
>> getVar to handle it.
>> e.g.
>> $app = JFactory::getApplication();
>> // Get the return url from the request and validate that
>> it is internal.
>> $return = JRequest::getVar('return', '', 'method',
>> 'base64');
>> $return = base64_decode($return);
>> if (!JURI::isInternal($return)) {
>> $return = '';
>> }
>> JRequest::setVar('return', $return, 'method');
>> // Perform the log in.
>> $error = $app->logout();
>> // Check if the log out succeeded.
>> if (!($error instanceof Exception)) {
>> The return check is shifted before logout and resets the return param
>> in the request. This solves any injection of the return method that
>> the particular chunk of code is protected against with the isInternal
>> check. As an aside probably not a bad idea to put that back in the
>> above chunk of code though I'm not sure why it was removed to begin
>> with. Then the logout is called where in the session is destroyed and
>> your plugin run. In there you can call JRequest::setVar() to reset it
>> and if it completes without error the user will be sent on their merry
>> way.
>> On Fri, Jul 6, 2012 at 9:07 AM, fanno <fan...@gmail.com> wrote:
>> > hmm i realise it is now a "development issue" but since i already have
>> > it
>> > here i hope it is on to keep going here rather than moving to joomla
>> > dev...
>> > $app->getUserState('users.logout.form.return') cant be used as after
>> > logout
>> > has happen becuase $app->getUserState(...) pulls from session data and
>> > since
>> > session is destroyed at this point it is "tolate" to retrieve it..
>> > This means it cant be brought in to work the same way. what other
>> > methods
>> > could be used ? that would work with both login/out ? or could something
>> > be
>> > change so that the actual kill of the session only happens after it is
>> > used?
>> > in this last location ?
>> > i have not look deep in to it but joomla user plugin:
On Tue, Jul 10, 2012 at 11:33 PM, fanno <fan...@gmail.com> wrote:
> Could we not get problems with filters on request?
At this point we're already in the request and we've done any input
filtering we might have done. The only other filtering would be in the
component itself when we use JRequest to get it back out.
> Or would all valid url characters stay intact?
Valid URL characters would remain untouched. It'd just be a string in
PHP's memory that we're manipulating.
> Maybe a public function somewhere to set and get redirect url would be better since we don't have to worry about older. Versions??
We could do that though the only way I could see of reasonably doing
it is to create a static method in a class somewhere. It isn't a great
deal to re-encode and decode it to retain compatibility though I think
we should have a more generic approach somewhere however until that is
figured out and works in this case where we're killing sessions, using
this interface is probably a reasonable compromise.
In a sense a much better way would be able to make the authentication
system more configurable in general so that the level of integration
you wish to provide is easy to handle.
A redirect hook called from system redirect? Allowing redirect to be change if a plugin wants it to.
The hook should be called from the core redirect function in my eyes. This gives a lot of flexibility i think.
I am not in core team or anything, but i don't feel like i cant make this decision. But I have seen such hooks from other systems/software and it seems to work quite nice. Not sure if this would affect performance. but since it should only call if plugin register for the hook ... it should not ?
My personal opinion would be that is much more "clean" than reuse the JRequest, there may be more data needed in the hook eg a status of some kind but i think the URL would be enough
-Thanks
Den torsdag den 12. juli 2012 07.16.34 UTC+2 skrev Samuel Moffatt:
> On Tue, Jul 10, 2012 at 11:33 PM, fanno <fan...@gmail.com> wrote: > > Could we not get problems with filters on request?
> At this point we're already in the request and we've done any input > filtering we might have done. The only other filtering would be in the > component itself when we use JRequest to get it back out.
> > Or would all valid url characters stay intact?
> Valid URL characters would remain untouched. It'd just be a string in > PHP's memory that we're manipulating.
> > Maybe a public function somewhere to set and get redirect url would be > better since we don't have to worry about older. Versions??
> We could do that though the only way I could see of reasonably doing > it is to create a static method in a class somewhere. It isn't a great > deal to re-encode and decode it to retain compatibility though I think > we should have a more generic approach somewhere however until that is > figured out and works in this case where we're killing sessions, using > this interface is probably a reasonable compromise.
> In a sense a much better way would be able to make the authentication > system more configurable in general so that the level of integration > you wish to provide is easy to handle.
We can add a plugin trigger as well, however what is the expected
behaviour at that point when more than one result is returned? What if
two plugins return a redirect? The standard plugin logic doesn't make
sense here as the option is a single one off item, it can only be set
once. Something more inline with the authentication system's use of
plugins where it handles each plugin itself. I'm not sure that it
makes sense to put this in JApplication::redirect and be able to
rewrite every single redirect request without any context around it
happening - you'd essentially be getting a URL without much context
(or having to do nasty stuff with debug_backtrace to find it) which I
can potentially see as interesting but limited application.
On Thu, Jul 12, 2012 at 5:50 AM, fanno <fan...@gmail.com> wrote:
> What are you thinking OnUserRedirect ?
> function OnUserRedirect($url) {
> reutn $url;
> }
> or
> function OnUserRedirect(&$url) {
> }
> A redirect hook called from system redirect? Allowing redirect to be change
> if a plugin wants it to.
> The hook should be called from the core redirect function in my eyes. This
> gives a lot of flexibility i think.
> I am not in core team or anything, but i don't feel like i cant make this
> decision. But I have seen such hooks from other systems/software and it
> seems to work quite nice. Not sure if this would affect performance. but
> since it should only call if plugin register for the hook ... it should not
> ?
> My personal opinion would be that is much more "clean" than reuse the
> JRequest, there may be more data needed in the hook eg a status of some kind
> but i think the URL would be enough
> -Thanks
> Den torsdag den 12. juli 2012 07.16.34 UTC+2 skrev Samuel Moffatt:
>> On Tue, Jul 10, 2012 at 11:33 PM, fanno <fan...@gmail.com> wrote:
>> > Could we not get problems with filters on request?
>> At this point we're already in the request and we've done any input
>> filtering we might have done. The only other filtering would be in the
>> component itself when we use JRequest to get it back out.
>> > Or would all valid url characters stay intact?
>> Valid URL characters would remain untouched. It'd just be a string in
>> PHP's memory that we're manipulating.
>> > Maybe a public function somewhere to set and get redirect url would be
>> > better since we don't have to worry about older. Versions??
>> We could do that though the only way I could see of reasonably doing
>> it is to create a static method in a class somewhere. It isn't a great
>> deal to re-encode and decode it to retain compatibility though I think
>> we should have a more generic approach somewhere however until that is
>> figured out and works in this case where we're killing sessions, using
>> this interface is probably a reasonable compromise.
>> In a sense a much better way would be able to make the authentication
>> system more configurable in general so that the level of integration
>> you wish to provide is easy to handle.
> To post to this group, send email to joomlabugsquad@googlegroups.com.
> To unsubscribe from this group, send email to
> joomlabugsquad+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomlabugsquad?hl=en.
