[Laravel 4] Activeert zichzelf op magische wijze?

[DennusB]

Hoi Tweakers,

Ik ben bezig een app te ontwikkelen in Laravel 4, dat gaat erg goed(werk er voor het eerst mee), maar loop nu tegen iets onverklaarbaars aan.
Ik heb een user tabel, met daar in (alleen even de velden die van toepassing zijn) : username, password, active (1 of 0), created_at & updated_at

In de registratie module doe ik dit bij het post :

PHP:

$username = Input::get('username');
$password = Input::get('password');
$password = Hash::make($password);
$email = Input::get('email');
$key = str_random(40);
$user = new User;
$user->username = $username;
$user->password = $password;
$user->activationKey = $key;
$user->email = $email;
            $user->active = 0;
$user->save();
//Send email
$data = array('username' => $username, 'email' => $email, 'key' => $key);
Mail::send('emails.registration', $data, function($message)
{
    $message->from('[e-mail]', 'website');
    $message->to(Input::get('email'), Input::get('username'))->subject('Activeren website.nl account!');
});

Prima, hij maakt de user aan en zet active op 0. Maar na 2 seconden is active opeens op 1 gesprongen.......
Als ik het e-mail stuk uitzet gebeurt dit onverklaarbare gedrag niet. Heeft iemand enig idee wat dit kan veroorzaken en hoe ik het moet fixen? Ik zoek me rot maar kan het niet vinden...

[ Voor 2% gewijzigd door RobIII op 15-09-2014 15:10 . Reden: Komaan; je loopt hier toch lang genoeg rond om [code] tags te kunnen gebruiken, niet? ]

[tim427]

Wat ik met Laravel altijd doe is het volgende:

Ik maak een functie bij het Model User genaamd active(); Deze kijkt of de activationKey empty is.

Bij het verifiëren van de activationKey check ik of die key klopt. Zo ja? Maak dan de activationKey leeg.

Scheelt weer een kolom en een extra unconstrained variable..

[DennusB]

tim427 schreef op maandag 15 september 2014 @ 15:17:
Wat ik met Laravel altijd doe is het volgende:

Ik maak een functie bij het Model User genaamd active(); Deze kijkt of de activationKey empty is.

Bij het verifiëren van de activationKey check ik of die key klopt. Zo ja? Maak dan de activationKey leeg.

Scheelt weer een kolom en een extra unconstrained variable..

Dat is inderdaad ook een prima optie! Maar het verklaart dit gekke gedrag helaas nog niet..

[Barryvdh]

Ik zou het zo niet durven zeggen, maar je kan bijv. https://github.com/barryvdh/laravel-debugbar gebruiken om te zien welke queries je precies uitvoert, eventueel kan je een backtrace optie aanzetten die misschien een indicatie geeft van waar je de query start. Misschien wordt er een link/plataje ingeladen ergens die hem activeert oid? (Je kan aan de rechterkant vorige requests doorbladeren dan ook, om te zien welke pagina's aangeroepen zijn en wat die voor queries deden)

[ Voor 17% gewijzigd door Barryvdh op 15-09-2014 15:20 ]

[DennusB]

Barryvdh schreef op maandag 15 september 2014 @ 15:19:
Ik zou het zo niet durven zeggen, maar je kan bijv. https://github.com/barryvdh/laravel-debugbar gebruiken om te zien welke queries je precies uitvoert, eventueel kan je een backtrace optie aanzetten die misschien een indicatie geeft van waar je de query start. Misschien wordt er een link/plataje ingeladen ergens die hem activeert oid? (Je kan aan de rechterkant vorige requests doorbladeren dan ook, om te zien welke pagina's aangeroepen zijn en wat die voor queries deden)

Dat is een goed idee... heb ondertussen volgens mij redelijk kunnen uitsluiten wat het veroorzaakt :

PHP:

<?php echo link_to('activate/'.$key, "Activeer nu", $attributes = array(), $secure = null); ?>

In de blade e-mail template...

[Barryvdh]

Maar dat zou niet de link moeten uitvoeren direct..

[DennusB]

Barryvdh schreef op maandag 15 september 2014 @ 15:23:
Maar dat zou niet de link moeten uitvoeren direct..

Blijkbaar doet ie wel zoiets, want als ik dat er tijdelijk uithaal gebeurt het niet meer

[tim427]

Is het niet een gekke SPAM-filter die de link checked?

Zet voor de grap eens in je "activate functie" de value op 99 ipv 1

[ Voor 39% gewijzigd door tim427 op 15-09-2014 15:26 ]

[DennusB]

tim427 schreef op maandag 15 september 2014 @ 15:25:
Is het niet een gekke SPAM-filter die de link checked?

Ah.... dat zou het nog kunnen zijn ja.... even proberen!

Edit : Jep......

92.*.*.* - - [15/Sep/2014:15:26:28 +0200] "GET /activate/tMQBQu8vrzx3mPkvTfgARBFTPCrnkwDgRtqFv92y HTTP/1.1" 302 1113 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)"

Wat een idiote spam ding... en ik zoek me er helemaal de tering voor

[ Voor 40% gewijzigd door DennusB op 15-09-2014 15:27 ]

[tim427]

Problem solved?

Ik heb hier nog nooit last van gehad met Laravel. Welke mail client gebruik je?

[DennusB]

tim427 schreef op maandag 15 september 2014 @ 15:28:
Problem solved?

Ik heb hier nog nooit last van gehad met Laravel. Welke mail client gebruik je?

Jep solved... als ik het naar m'n Gmail laat sturen is er niets aan de hand. Ja er hangt volgens mij een Baracuda voor hier, misschien doet die het nogal agressief?

[tim427]

Basacuda IDS Die zal hoogstwaarschijnlijk wel controleren voordat hij het aan jou voorschotelt

[deadinspace]

DennusB schreef op maandag 15 september 2014 @ 15:25:
Wat een idiote spam ding... en ik zoek me er helemaal de tering voor

Nouja, een request met server-side state changes zou dan ook geen GET moeten zijn eigenlijk

Toegegeven, dat is wel lekker makkelijk voor een activatie-mail, maar eigenlijk is het gewoon fout en dit is een goed voorbeeld waarom.