Force flashdata to exist right now, not for next request.

[eluser]gh0st[/eluser]
In a bid to reduce CSRF I'm wanting to add a session token as explained in this article (
http://shiflett.org/articles/cross-site-...-forgeries) on my form.

Code:

// controller
$token    = uniqid(md5(mt_rand()), true);
$token_time = time();
$this->session->set_flashdata('token', $token);
$data['token']    = $token;
$this->load->view('page', $data);

Code:

// view (just outputting the tokens to see if they match)
<p>
&lt;?=$token;?&gt;
</p>

<p>
&lt;?=$this->session->flashdata('token');?&gt;
</p>

But the thing is that the session token is always the "last" request, so it will always be incorrect.

What I want to do is to force create a flashdata item to exist right now, and not for the next request.

How do I do this?

Many thanks.

[eluser]TheFuzzy0ne[/eluser]
To my knowledge, there is no simple way to achieve the results you're looking for. Flashdata exists specifically for the request "after" the one that sets it. If you need access to it straight away, you need to use either $this->session->set_userdata(), or a local variable.

In your code above, it makes no sense to me why you set both $data['token'] and $this->session->set_flashdata('token') with the same variable. In this case, the token and flashdata will always be identical, so there's really no need to test this.

[eluser]gh0st[/eluser]
In the first time around they will be the same, but on the search results page the token should be different.

I'll just use:
$this->session->set_userdata()

as suggested.

[eluser]Colin Williams[/eluser]
Since you reset the token before validating against it, you are always going to get a true condition, as the FuzzyOne suggested. (Unless your view runs before your controller!)

[eluser]gh0st[/eluser]
The first controller generates the token, but the second one (where it goes to) only checks it against the session.

I haven't posted the full code because of size/readability issues.

IE:
1. First controller
a. Generate a token, put it into the session and spit it into the page, probably a form which launches...

2. Second controller
a. Get the session tokens and the form token and compare them to ensure they are the same.

[eluser]TheFuzzy0ne[/eluser]
I still don't see the issue.

If you want to dump the token out when it's generated, use the $token variable, if you want to get it back on the next request, get it from the flashdata array.

Controller method 1:

Code:

// Generate the token
$token    = uniqid(md5(mt_rand()), true);

// Set the flashdata.
$this->session->set_flashdata('token', $token);

// Pass the variable we generated through to the view and load it
$data['token']    = $token;
$this->load->view('page', $data);

Controller method 2:

Code:

// Get the token from the post array.
$data['token_from_form']    = $this->input->post('token');

// Get the token from the flashdata variable.
$data['token_from_session'] = $this->session->flashdata('token');

/**
* Do some validation stuff here. Check that the post token exists and
* is valid, compare the two strings etc...
*/

Load the second view.
$this->load->view('page', $data);

Am I overlooking something here?

[eluser]TheFuzzy0ne[/eluser]
Don't forget. All of this breaks if the user disables cookies.

[eluser]gh0st[/eluser]
Oh I see.

As I mentioned previousily, I am using $this->session->set_userdata()

[eluser]TheFuzzy0ne[/eluser]
That still requires cookies.

[eluser]simshaun[/eluser]
Using sessions without having any cookies is unavoidable unless you want the session id in the url (bad idea).

I assume TheFuzzy0ne knows this already, but just in case:

If you set your sessions to save in the database, then there is only one cookie that CI manages on the client-level. It contains User agent, session id, etc... this cookie MUST exist on the client's computer for CI to know that a session is set for the client. When a user accesses a page which uses sessions, CI looks for this cookie. If found, it looks for a matching row in the database. If not found, well I'm not exactly sure how CI handles this. With native PHP sessions, PHP would check the URL for a session id (if enabled in php.ini). My guess (without testing) is that CI doesn't do this and just tells you a session isn't set.

Anyway, if a user has cookies disabled, most likely he knows it.
If having sessions is important to you (ie: for protected areas), then you need to tell the user to enable cookies before they can login. Try logging into GMail with cookies disabled and you'll see what I mean.