Aye - so looking at the code you need to pass the referring URL to the form from executeSignin. In the form them append the referrer to the post request with something like "&referrer=url". Then in the isValid codeblock - pull out the param and use it in your redirect.
-----Original Message----- From: symfony-users@googlegroups.com [mailto:symfony-us...@googlegroups.com] On Behalf Of nick Sent: 15 May 2009 20:05 To: symfony users Subject: [symfony-users] Re: do i directly edit sfGuardAuth signinSucess.php if I want to customize the signing form, or do I override it elsewhere? On May 15, 5:23 am, "David Ashwood" <da...@inspiredthinking.co.uk> wrote: > There's a couple of places that tend to cause confusion when people try to > override Symfony & plugin functionality and the autoloader doesn't help when > you're trying to test things out. > > You can generally create your own version of any class - if you put the new > version in the right place and if the file and class are named properly. > The location you put the file depends on a number of factors and the scope > you want to affect. > > With plugins generally the best approach to start is to be as local to your > Symfony app as possible. > > 1. Clear your cache - it doesn't hurt to do this before and after you > start making changes and it's a good habit to do this often > 2. Start by making a folder for the in > apps\<applicationName>\modules\<pluginName> (often you just make the folder > rather than using the generator) > a. Depending on what you're overloading you create the sub folder here > for it - so if you're modifying a template then create a templates folder > under the plugin folder you just created > 3. Now copy the existing file from the plugin to the folder you just > created- it'll be a good starting place to making any changes. When copying > a file it's the file that will be used initially by the autoloader rather > than a file named Base.. > a. So if you're looking to override the actions then, for sfGuard, it's > going to be under the modules\sfGuardUser\actions\actions.class.php > b. Well written plugins will also have a base file - for sfGuard this > is BasesfGuardUserActions.class.php - which allows easy overriding of your > own functionality > c. You'll need to change the require/require_once statement in the top > of this copied file to point to the correct place as when you override the > autoloader won't be able to find the class you're trying to include. > d. This file will generally just be a placeholder - with all the work > being done in the parent class. You'll need to refer to the base class or > have a decent IDE that gives you code assist or exploring of the methods in > the parent to determine what method signatures are available for you > 4. Now you can implement your own functionality in the file - for an > action start with something simple like overriding a method and putting > die("hey - it worked! - Who's da man?!?!") > 5. Clear your cache again and fire up your browser to load a page under > the application you used above > 6. Now you see your die statement is being hit - you can implement the > actual code you want to happen That's interesting that you test the code by putting in a die() statement. I do the same thing. But that has not been a problem in this case. I was able to override the plugin classes without any trouble. I saw my die() statement fire as soon as I had overridden sfGuardAuth. My problems started after that. > Regarding your specific issue of capturing the source page where the use has > come from - you want to override the actions for the plugin and store the > referrer before sfGuard starts its own redirects - otherwise you'll lose the > information in the chain of redirects that happen. Most people append the > referrer to the URL as a parameter Yes, of course, but that isn't working for us. As I explained in an earlier post: When I look in BasesfGuardAuthActions.class.php, I see this code: $this->form->bind($request->getParameter('signin')); if ($this->form->isValid()) { $values = $this->form->getValues(); $this->getUser()->signin($values['user'], array_key_exists ('remember', $values) ? $values['remember'] : false); // always redirect to a URL set in app.yml // or to the referer // or to the homepage $signinUrl = sfConfig::get ('app_sf_guard_plugin_success_signin_url', $user->getReferer ('@homepage')); return $this->redirect($signinUrl); } We want the page that the user was trying to get to, which isn't treated as the referer on my machine. For instance, if I am at the home page, and then I try go here: index.php/wiki/show/id/54 The home page is treated as the referer. But after the user signs in, I want them to end up here: index.php/wiki/show/id/54 The address I want is in getUri() instead of getReferer(). However, if I change this: return $this->redirect($signinUrl); to this: return $this->redirect($request->getUri()); then I end up with an infinite loop of redirection. If I embed getUri() in the login form, and then submit it, and capture it as a parameter, and then use it in the line above, I still get an infinite loop of redirection. Ideally I could use $this->forward(), but this forward usually takes a module and action like this: $this->forward('question', 'index'); I think it would be a lot of work for me to fetch the id and squeeze it in there. I could also drop out of Symfony and do this: header('Location: ' . $request->getUri()); I tried this but it simply doesn't work. Nothing happens. Symfony somehow smothers this. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
