Thread

Bernd,

What do you think about putting the subject and stuff in the config file? 

Do you prefer the template?

Ben,

I would much prefer the template. It is so comfortable to put text and functions in it. Or changing it from text to html for example.

In our project we will have a lot of different emails in different languages, with personal infos for the user, like reminders etc.

So I will put all of them into email templates, load lines from language files or text from database and so on.

I think, sending emails from views is a good practise.

Best regards
Bernd

Ben,

perhaps it would be a good idea to take the email out of the register (forgot password etc.) method and put it into a separate email method. This could be done in the controller, because sending emails has nothing to do with authentication.

Now, instead of only returning bool, the registration method could return an array with relevant information like id, activation-code etc.

The controller could look like this:

if($register = $this->ion_auth->register())
{
    //do something with $register like sending a confirmation email 
    //or telling the new user his user-number
    //or update the new user-record with some calculated data
}
else
{
    // registration failed
}

So the functionality, look and feel of the emails can be totally controlled by the programmer.

What do you think?

Best regards
Bernd

I’d rather not. The entire point of Ion Auth is that it’s simple, lightweight and helps the programmer out. That complicates matters and makes the implementation a little lengthier.

As far as “email has nothing to do with authentication” goes, sure it does. Perhaps we could have a register() and an insert_user() function, one does the whole shebang and the other just literally inserts the user.

Phil,
a separate email-method could also be situated in the library file and accessed by the register-method.

It would not be less lightweight.
But it would give the programmer the possibility to design his emails without changing the library.

Bernd

I get that, it’s just more hassle and involved current users of the library changing their applications for no real reason.

Could you suggest a way to get the same functionality without buggering up the register() method?

append an additional parameter $send_email = TRUE

if($send_email)
{
    //send email like before
}
else
{
    return $data;
}

Thank’s for suggesting an if statement, I only wish I had thought of that!

Perhaps a config item could be added (defaulting to true) and if set to false it won’t send emails.

The true clause could contain the email code moved to its own method so it can be called separately. It’s all on GitHub so fork and commit!

Hi guys

I’ve been looking at the code and I would like to implement Ion Auth twice on the same site. Now I can obviously do this via the config files so that one uses a “customers” table and another uses a “admin” table, but if I want both of them to use the “email” field as the identity won’t they clash?

Glennj,

Why not just use groups?

internut,

I’m not exactly sure what your asking…

If you are asking how to insert a user without any meta data then just pass an empty array as the additional data to the register method.

Glennj,

Why not just use groups?

I could do I suppose, just felt I would like a distinct seperation in the database and I’d want to use different email templates, meta data etc for the different groups.

GlennJ,

I really don’t recommend separating the users.  It might sound like a good idea now but it makes things horrible to work with later on.

I would recommend having different groups and then if you need additional customer data that won’t work in the meta table you can create another table with a relationship to the user; you shouldn’t need to do that though.

Yeah, I do understand where you’re coming from and I understand the pros and cons.

I think for a blog or CMS that would be fine, but security is paramount on this site and the users have absolutely nothing in common.

I’ll have a think… 😉

Cheers.

Yeah, I do understand where you’re coming from and I understand the pros and cons.

I think for a blog or CMS that would be fine, but security is paramount on this site and the users have absolutely nothing in common.

I’ll have a think… 😉

Cheers.

As far as authentication goes, everybody is a user right? Everybody needs a login, everybody has an email.

I have done all sorts of crazy things with Ion Auth that a user auth system wouldn’t handle, the best example being a multi-site, reseller account with public users, reseller customers (running the sites that the public users look at), resellers (managing the reseller custom accounts) and super-admins who manage the resellers.

These are all run off one “user” database and have groups.

Security here is clearly paramount, but as long as you code right there is no problems at all.

You could do this purely with groups, or you could have users, customers and admins as separate tables.

“users” would handle the basic data, then customers and admins would both have a user_id field and contain extra info.

Then just add a “type” enum(‘customer’, ‘admin’) field to your database, and use the built-in hidden awesomeness that is:

$this->ion_auth->extra_where('type', 'customer');
$this->ion_auth->extra_set('type', 'customer');

This means any new users will be customers, and it will only look for customers on login.

Put that in global code like named base controllers and you are all set.