Welcome Guest, Not a member yet? Register   Sign In
CI4 User Authentication System
#11

(03-03-2017, 11:07 AM)ajturner Wrote: This will be treated primarily as a model since it requires MySQL database access. It will have basic templates for controllers and views that for users to start from, if needed.

Here is a current list of goals for initial release:
  • Create a website for communications and discussions
  • User login and registration
  • Password recovery (forgot password, username, etc)
  • Login attempt logs with IP address tracking
  • Lock out users for specfied amount of time after a number of failed attempts
  • Generate email messages that can be insert into the developers email method of choice

So ... an already working application, without the business logic in it. Smile

(03-04-2017, 06:40 PM)skunkbad Wrote: From you issues:

Quote:Need to determine what packages to include in final release.

   Password hasher
   Any Security packages
   Emailer

Should also determine if these packages should be included in the UserAuth namespace or within their own namespace in the CodeIgniter application.

The bolded line in that quote is the real problem ... Security isn't a thing you install.

(03-04-2017, 06:40 PM)skunkbad Wrote: ...

Password hasher? What's wrong with PHP's native password functions?

Nothing.

But, while the OP probably listed that for the wrong reasons, there's plenty of room for abstraction on top of PHP's ext/password.
So, here's a shameless plug: https://github.com/ITCover/PasswordProcessor (the README explains what I mean)

(03-04-2017, 08:30 PM)PaulD Wrote: Take 'forgotten password' for instance. There are so many ways to do just that alone. Secret questions, emailing reset links, emailing codes to reset, sending temp passwords, second one time use passwords, sending random passwords, human moderation of password resets etc etc.

I'd argree on your point in principle, but have to disagree on this example ...

Secret questions are a no-go. Period.
Emailing password reset codes or links is very much the same thing.
Emailing temporary passwords is essentially the same thing as emailing password reset codes.
Temporary passwords must always be only for one-time use (hence the last point above)
Any password (or code/token) you generate must be random regardless of what you do.
Human moderation can be useful only in closed, intranet-style systems, but even then - don't forget that humans are always the weakest link.

So ... You drop 2 of these (first and last), see that another 3 are the same basic thing (one-time token/password) and then note that the only remaining thing is a requirement for the former basic thing.
Not much choice really.
Reply
#12

Please do not tie this to a specific database.I would love to use this with PostgreSQL.
Reply
#13

Hey everyone, I've read a lot of great comments so far. I'm always welcoming of feedback and ideas and I appreciate the respectfulness from all of you.

I would like to clarify a few things that have been pointed out:

1. Skunkbad, you mentioned I haven't even started yet and wondering why I'm doing this or that:

In reality, I have started. I'm currently in the discovery and planning phase. This is essential to start before any coding even takes place.

Here's what I'm doing:
  • I'm identifying any workflows that this program needs to be able to do and basically creating flow charts for each action and possible outcomes.
  • I'm looking for possibilities for pre-existing code to include. That includes a PHP hasher or security focused code.
Why am I looking at possible PHP hashers? Is the included functions with PHP enough or do we want to abstract that process like Narf mentioned?

Emailer? CI4 is supposed to have one built in, but will it be sufficient? How does it do with spam filtering? Would we want to implement our own to address those issues or simply use the CI4 built in one?

Creating base templates and controllers isn't a bad thing, like you make it sound out to be. Good documentation is always a must, but why would it discouraged to create a working example?

These are all questions I'm exploring to determine what is needed before I start coding.

To be a CI4 standard? Never hurts to dream big, eh?   Big Grin

2. PaulD, Narf summed it up pretty well with his response about the example. I'll just add that bloating shouldn't be a major concern since these files are not even loaded until called upon. The main concern would be the overall size of the file, but I believe that will still be kept to a minimum.

3. qury, I haven't put much thought into it yet, but fortunately, if I were to follow good coding standards, any database interaction would be abstracted anyway. that way we can easily extend the functionality to include PostgreSQL. Once this is done, I have a project in mind that could benefit from using MSSQL as the software it is based on uses that, so adding functionality to other database types is important.

------------------------------------------------------------------

I'm not saying these things to be defensive, because I am very appreciative for feedback. Just keep in mind the engineering process, when done right, is slow. It all starts with the planning phase. Getting input from potential users is crucial as to get feedback for currently listed concepts or what should be added or potentially taken away. This all has to happen before any coding even starts.

Thanks again!
Reply
#14

(This post was last modified: 03-06-2017, 07:41 AM by Narf.)

(03-06-2017, 07:14 AM)ajturner Wrote: Why am I looking at possible PHP hashers? Is the included functions with PHP enough or do we want to abstract that process like Narf mentioned?

Here's the thing ... If you'd be building a reusable authentication package, it is supposed to handle that on its own, and you knowing how to handle this already is an essential requirement.

The abstraction I was referring to is tricky to achieve in a reusable manner, because:

- The fact that password verification is so closely tied to your users management logic, and that in turn is almost always tightly coupled to business logic too
- Different storage strategies/database structures
- Legacy hashes

You have neither of those concerns, and while a library like the one I linked may indeed help you in your project, I do maintain that you're into it for the wrong reasons.

You shouldn't be looking for what components to use, but what are the problems at hand and how to solve them. If hashing is one of the problems, and you can't do it without a "hasher library", then I cannot trust you to build an authentication system for others to use.

(03-06-2017, 07:14 AM)ajturner Wrote: 2. PaulD, Narf summed it up pretty well with his response about the example.

I didn't sum up anything. I only demonstrated that PaulD's example was a bad one.
Please note that I started my reply to him with agreeing on principle, and then disagreeing explicitly on the particular example he gave.
Reply
#15

(03-06-2017, 07:41 AM)Narf Wrote:
(03-06-2017, 07:14 AM)ajturner Wrote: 2. PaulD, Narf summed it up pretty well with his response about the example.

I didn't sum up anything. I only demonstrated that PaulD's example was a bad one.
Please note that I started my reply to him with agreeing on principle, and then disagreeing explicitly on the particular example he gave.

I wasn't disagreeing either  Smile

In fact, he does raise a potential problem that should be looked at for possible solutions. I personally don't think it'll become bloated, like he suggests, but I may be proven wrong as the project moves forward.

Bear in mind, I didn't list a specific method for password recovery, other than saying password recovery needs to be a part of it. The actual method is to be determined (whether we send the man email with temporary password or a link, etc). But with that brings up additional concerns such as the security of sending reset links through email. This is why I also mentioned two-factor authentication as a possibility.

------

Again, these comments are helping me narrow down what I need to be focusing on. I'm taking notes as I read through them. Keep them coming!
Reply
#16

(This post was last modified: 03-06-2017, 10:25 AM by qury.)

I wonder whether Ben Edmund's https://github.com/IonAuth/IonAuth could be forked and updated as part of this project, it would give a head start i think.
Reply
#17

(03-06-2017, 10:25 AM)qury Wrote: I wonder whether Ben Edmund's  https://github.com/IonAuth/IonAuth could be forked and updated as part of this project, it would give a head start  i think.

thats the wrong link for the current version of ci ion auth - correct link is:
https://github.com/benedmunds/CodeIgniter-Ion-Auth
Reply
#18

(This post was last modified: 03-06-2017, 12:32 PM by qury.)

(03-06-2017, 11:13 AM)cartalot Wrote: thats the wrong link for the current version of ci ion auth - correct link is:
https://github.com/benedmunds/CodeIgniter-Ion-Auth


Well i know the correct link to the Codeigniter 3 specific Ion Auth package.
The reason i've linked that other one is that it is not specific to Codeigniter and is already psr-4 compliant.

I know that the last update in that repository was done in 2015, that is why i suggested that it could probably be forked and updated to current requirements and maybe kept framework agnostic.
ben has confirmed that the project is completely abandoned...

I believe that if an auth library is kept framework agnostic there is a higher chance of other developers contributing to it as well, hopefully raising the quality of the code.
Reply
#19

@qury

"framework agnostic" - this is practically impossible. I've implemented CI3-based authentication in the past (registering, user management, login, password recovery, the usual stuff...) and it alone is really a whole application. Smile Features provided solely by the framework are needed - configuration, routing, page rendering, mailer, database access (with a query builder or something more complicated). Even if "framework agnostic" is technically possible, the result would be a ugly beast, hard for integration and maintaining.
Reply
#20

Because every full size framework has their own implementation of session handling, it'd be very difficult to have a framework agnostic authentication. You'd end up with a bunch of drivers. You also have to consider database handling, but you could technically use two DB connections at once. That's not so easy to pull off with sessions. I've actually been thinking about such an authentication system, and I did find something called Opauth, but it uses a bunch of "strategies", which may just be drivers. I didn't take a good look at it.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB