Thread

@Paul
Looks interesting there 😊

@humungus
Sorry, i cannot answer this question, since when i learned PHP it’s already version 5 and always use this version, i just tried to write as compatible as possible. Maybe someone who already dig the code might give you a better answer. Btw, which line is the error?

@paul…

thanks for the contribution!

But, please do not post that much code in the forum thread - not only is it difficult to read, the forum often messes up the code and other readers can’t copy paste it without getting a bunch of errors.

Create a wiki page and link your zip file with all the different files bundled into one download. that way, anyone can just grab a copy and open all the files locally in their own environment without a lot of manual copy paste steps.

cheers.

@dexcell

i receive blank pages if i auto load DX_auth library through config

i test it without auto loading (no loading the library at all) and the page was presented up to the point i use a DX_auth function for the first time

that shows me that my host service cannot parse DX_auth code due to a possible incompatible (to my host version) PHP function or syntax you use on your library,
with my minimal experience in PHP i doubt that i have a chance to find out which or what, i was hoping that someone had fall into this in the past

thus :
i have either to get a new host service, or ask my host to upgrade his PHP version :?

thanks for contribution Paul!

Paul:

is that all the code or just snippets? I am not sure if I missed it but do you have this code in WiKi or together in ,say, zip file?

Thanks

Hey, I see the you built a “hooks/events” library of sorts. Would you be interested in just extending the core hooks class to offer all that functionality? I built an extension of the core hooks class (with some sample code) that would allow you to call hooks (anywhere) in the same form users are already calling the core CI hooks.

Extra Hooks

I love the uri_permissions however - do you think that rather than listing ALL possible uri’s to protect - we could just list the ones that we DON’T want a user to access?

I guess in that case we could just stick with is_role(‘admin’) and skip the uri_permissions().

I love the uri_permissions however - do you think that rather than listing ALL possible uri’s to protect - we could just list the ones that we DON’T want a user to access?

I guess in that case we could just stick with is_role(‘admin’) and skip the uri_permissions().

Depends on your project, not sure it is faster…

If you specified the pages you don’t want to protect, but in the other hand have to edit protected controllers to set up the type of permissions, this is a loss of time.

Maybe i’m wrong about the way you suggest to do.

Well, I think that if I had 10 controllers with 4 methods each (40 possible pages) it would be easier to just ban users from the 2 backend controllers (and there 4 methods) than it would be grant access to all 8 controllers (minus the 2 backend controllers).

Does that make sense?

Yes,

But you just have to do not protect yours controllers, except the two of your backend.

In my application, my backend is in an “admin” subfolder. This is the only one I protect.

I clearly understand that you mean, and think there will be as many opinions as reader of this post 😊

Yes, But you just have to do not protect yours controllers, except the two of your backend.

Could you explain that again? Because that sounds like just what I was saying.

In my case, if I don’t want to protect a controller, I simply don’t use check_uri_permissions() (or is_admin() / is_role() ) in this controller.

And I don’t need to allow access in the DB.

By the way, I saw you release new unofficial version of redux auth. Will take a look on this library 😊

if I don’t want to protect a controller, I simply don’t use check_uri_permissions()

Duh, why didn’t I think of that!? That would only leave me to setup rules for the controllers I NEED!

I’ve been too long in the standardization movement - I’m starting to lose it…

Bug (v. 1.0.4 ):

in models/dx_auth/user_temp.php

Lines 31 & 37 should read

return $this->db->get($this->_table);

not

return $this->db->get($this->_user_table);

This only seems to appear when configured to only allow logins with email address, i.e.

$config['DX_login_using_username'] = FALSE;
$config['DX_login_using_email'] = TRUE;

HTH

^
Thanks. Fixed it.

Updated the library to 1.0.5 version,
Only permissions and user_temp model is updated.