• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Why can't I do this in CI?

I do believe everybody who posted "actually tried to help".

I'm sure you're saying something because you're taking personal offense since you know your post was one of those that weren't helpful at all. You suggested me to not use CI if I was going to make my own classes, was that the best help you had to offer? Doubt it.

Nobody besides Aken focused on my actual issue. People told me ways to work around my issue, but besides him not one other person actually focused on my issue.

That's why I said "actually", to show the one or two others that tried to help gratitude. You and one other did not help with my issue in the slightest and were quite rude in this matter.

This is a support forum, not a suggest ideas you think are better forum. This topic should have been closed after my last post.

If you say so, good sir.

Yunohoo, telling people that don't know you or what you're working on to "not assume" is nearly impossible, because the only info we have to understand your problem is what you've posted in this forum. We don't know what else you're planning on adding or changing, what level of experience you have, or anything else. So try not to get offended if someone expresses an opinion based on what limited information they have available. CroNIX didn't tell you not to use CI, he said he doesn't see why you would use CI if you didn't utilize the native features. Again, he doesn't know that you already are for another kind of session. And trust me, we all see some awful code come through here and very few people are willing to take constructive criticism, even if that means telling them to go back to the basics.

Regarding your issue, let me try to break down the process that is happening in CodeIgniter, and why it isn't "working" in the sense that you're expecting.

1) You access your admin section via the admin/index controller/method. The session library is loaded, and _session_id is empty (NULL). The session constructor tries to find a matching session value (which should be fixed - it should only look for a value if one exists). It does NOT, so nothing else happens.

2) Your index() method looks for a valid session. It does not find one, so it calls the admin_login() method.

3) Ignoring the POST check (since we don't have any POST data), we skip to some variable assignments and loading of a view. Your login form is shown on the page. I am under the impression that the login form will be processed in the same admin_login() method.

4) Your form is submitted. A new page is loaded. The session library is now newly instantiated. All of its properties have any default values, and the constructor runs again. Once again, it finds no matching session, so nothing happens.

5) Your admin_login() method is called. The "process" POST variable exists, so we process the login. The username and password are checked in the Admin::authorize() method. Let's say that the authorization is successful, and it returns a valid $user array.

6) Your admin_login() method receives the valid $user array. It creates the $session_id variable. You then successfully call the set_session() method, which assigns the _session_id property in your session library to the appropriate session ID. At this point, it is set and exists. That's the only change to the session library.

7) Your admin_login() method continues to set some data in the database. It then redirects the user to the admin homepage again. Upon redirecting, the _session_id property is GONE, because a new page load has occurred, and the class has been instantiated again, reverting to its default state.

8) End up right back at step 1.

Properties are only accessible to a class during a single instantiation. You are being confused by your example because the _session_id is NOT being passed through the page request. It is being created after the form is submitted and the page reloads. Try putting a redirect after you set the session ID and see if it's there after - it won't be.

Honestly, there's nothing wrong with using the standard session class to handle both regular users and admin users. Just make sure you set up the necessary checks and precautions. Adding a completely separate sessions class for admin is just making more redundant work for yourself. And what makes yours any more or less secure? Any methods someone could use to exploit the regular user session could be used to exploit your library. We're not saying don't use CI if you want to make your own libraries - that's absurd. We're saying why bother reinventing the wheel, when a perfectly good session class exists that will satisfy your needs perfectly fine.

Good luck with your project. Hopefully you learned something from this. I suggest reading more about OOP PHP, object properties and more on PHP.net - tons of useful information there that will help.

Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  

  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.