I have a website based on Codeigniter which works fine. I had to clone this site with database to an another host. I copied the database and all files. My problem is: the session doesn't work on the new site. (I recognized it at the login). The same code works on the old host, but everything is exactly the same.
Does somebody have any idea? Is it a codeigniter configuration issue?
Thanks
Check your application/config.php
especially these lines:
$config['cookie_prefix'] = "";
$config['cookie_domain'] = "";
$config['cookie_path'] = "/";
$config['cookie_secure'] = FALSE;
Also: please delete your cookie-history
(if you're using Firefox: CTRL-SHIFT-DELETE)
Alternatively you could use (shameless self-plug) codeigniter-native-session
I too had a bit to much problems with the built-in session engine.
It basically mimics the Codeigniter session class so just drop in these files into your application folder and code doesn't needs any modification. (and you'll be using PHP-native-sessions)
Hope it helps.
Related
Just migrated my CI from localhost to live. Everything works fine on localhost with same settings.
Here're the folder/file structure and contents of routes.php
-application
--controllers
---Home.php
--modules
---specs
----controllers
-----Specs.php
----models
----views
$route['default_controller'] = 'Specs/index';
//$route['default_controller'] = 'Home/index';
$route['404_override'] = 'Errors/show_404';
$route['translate_uri_dashes'] = FALSE;
Both Specs and Home controllers have index method. When I load the home page url with Specs/index as default controller, I get 404 error. But if I change the default controller to Home/index, it loads just fine. Strange. Everything else works just fine on whole site. Can't figure out.
The website is live but I'm not sure if providing url is allowed, so I'm including spaces in it. It's unspecs dott comm. Admin/Mods may please remove if url isn't allowed.
Thanks for reading.
I think you are doing mistake in routing, for HMVC it should be like that -
$route['default_controller'] = '<folder name>/<controller name>/<function name>';
$route['default_controller'] = 'specs/Specs/index';
Please follow this, hope it will work fine.
Try this https://stackoverflow.com/questions/6529026/codeigniter... But better use standart folder for default controller /application/controllers
I'm struggling with a session issue so bizarre, I don't even know how to start debugging it.
I have a CI 3.0.0 project that has been up and running (and constantly being developed) for several years now.
Last week I switched to a new hosting service, and ever since then, I've been experiencing session issues, where session data keeps resetting at various intervals.
The switch to the new host was done by the hosting company - they say they copied the whole cPanel account as is, including files & database. One change I did make on the new server is defining the cookie_domain, which was previously unset, to ".mydomain.com".
When I started having problems with the sessions, I changed it back to $config['cookie_domain'] = ''; but that did not help.
My session/cookie settings in config.php are as follows:
$config['sess_driver'] = 'database';
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 14400;
$config['sess_save_path'] = 'ci_sessions3';
$config['sess_match_ip'] = FALSE;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = FALSE;
$config['cookie_prefix'] = '';
$config['cookie_domain'] = '';
$config['cookie_path'] = '/';
$config['cookie_secure'] = FALSE;
$config['cookie_httponly'] = FALSE;
I use sessions mainly to hold user login details, and here's what I use in my basic page template, to check whether the user is logged on and has the appropriate permissions. If they do, I load the requested page view. If not, I load the login form.
What happens now is that after the user has logged on and started using the system, after a very short time, they are thrown back to the login form, as if the userdata has been somehow reset.
if (!$this->session->userdata('admin_logged_in') || empty($this->session->userdata('digital_view_perms')))
{
$main_content = 'admin_digital/login_form';
}
$this->load->view($main_content, #$data_rows, #$prev_code, #$action);
Any pointers as to where I should start digging for problems would be highly appreciated!
The only thing I know for sure has changed is the hosting service. The php version on the new server is 7.0.28, whereas the php version on the old server was 5.6.33.
Thanks!
I had this problem when I changed the php version to 7.0
Download the latest version of CI3
Replace the System/ folder by the new one!
You need to update your framework to the latest version for it to work with PHP 7
Update your framework! To fix that issue
I am trying to make an SEO friendly link for a downloads page
using codeigniter hosted on Azure Websites, now this is working:
www.example.com/downloads/viewfile/34
now when i generated this link :
www.example.com/downloads/viewfile/my-nice-file-name-34
the Url rewrite works great locally on a WAMP server, but when deployed to the remote (Azure Webites IIS ?) it gives the error:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
I believe that the cause is: dash symbols are not allowed on IIS but is there a way arround ?
After all, i found out that its not the dash symbols that are causing the problem, but the words in the url itself
like yesterday i had www.example.com/downloads/viewfile/example-file-34
to some reason, having your domain-name in the url segments makes that error apear, so i simply replaced "mydomain" into nothing before generating the Url segment
$fileName = str_replace('mydomain','',$fileName);
return url_title($fileName.$fileId);
Now the same link above is www.example.com/downloads/viewfile/file-34 and its working fine.
i also noticed that same behavior is experienced when using some words like : ajax, json.
I hope this would be helful to somone.
In your routes.php file
Find
$route['translate_uri_dashes'] = FALSE;
Replace with
$route['translate_uri_dashes'] = TRUE;
You may need to look also into
URI Routing Codeigniter 3
http://www.codeigniter.com/user_guide/general/routing.html
Codeigniter 2 URI Routing
http://www.codeigniter.com/userguide2/general/routing.html
I just moved my current office Joomla 1.5.8 instalation from the server(linux) to my local machines (winxp) so I can work locally and only upload the changes.
The thing is after downloading all the files and installing a backup of the remote DB on my local machine I found myself unable to login to the administrator panel, I can see the frontpage but not login :/
So far, I have googled alot this problem, but most people seem to be experiencing this problem while upgrading from joomla 1.0
To make sure the problem was not on permissions for the files,I did a separate brand new joomla instalation on another folder and it worked just fine, I could access the website and I also could login to admin page, then I changed the config file to connect to the joomla I'm trying to move and now I find myself again unable to login :/
I think the problem is on the DB however I already tried searching for specific paths but no luck
Does anyone has another Idea?
thanks in advance :)
Try to change following variable in your local configuration file with you local values.
var $offline = '0';
var $log_path = 'Your local joomla path\logs';
var $tmp_path = 'Your local joomla path\tmp';
var $live_site = 'local url will be here';
var $dbtype = 'mysql';
var $host = 'local db host';
var $user = 'DB user for local';
var $db = 'Db name for local';
var $dbprefix = 'DB prefix whatever you have set, by default jos_';
var $password = 'your DB password for local';
You probably have LDAP or openid authentication enabled and thats what is causing this blank page while you try to login.
Just go to your database and go to your:
jos_plugins
And edit the plugins which are either openid or LDAP
set their published status from 1 to '0'
Case solved.
Does your site use any kind of extra authentication? Mine used the LDAP Authentication plugin. MY local machine couldn't connect to the LDAP server. After turning LDAP authentication off (only use Joomla authentication) it worked.
edit the jos_plugins table in mysql to set published from 1 to 0 for any extra authentication plugins you are using.
I have discussed this issue in details here: http://www.itoctopus.com/blank-page-on-joomla-login
In most cases we have seen, Joomla is trying to load a file that no longer exists.
I'm still new to code igniter and I'm having problems getting the login system to work.
The login always works when I use Firefox. The login consistently works on some IE7 browsers but consistently fails on other IE7 browsers.
When tracing the code, I see that the models/redux_auth_model.php does successfully authenticate the user, it writes user information into the $this->session->set_userdata() and it redirect them to a member's page of my choosing. Here's the code:
public function login($identity = false, $password = false)
{
$identity_column = $this->config->item('identity');
$users_table = $this->tables['users'];
if ($identity === false || $password === false || $this->identity_check($identity) == false)
{
return false;
}
$query = $this->db->select($identity_column.', email, password, group_id')
->where($identity_column, $identity)
->where('active', 'Active')
->limit(1)
->get($users_table);
$result = $query->row();
if ($query->num_rows() == 1)
{
//$password = $this->hash_password_db($identity, $password);
if (!empty($result->activation_code)) { return false; }
if ($result->password === $password)
{
$this->session->set_userdata($identity_column, $result->{$identity_column});
$this->session->set_userdata('email', $result->email);
$this->session->set_userdata('group', $result->group_id);
return true;
}
}
return false;
}
I did a variable dump of $this->session in both IE7 and FF and confirmed that all the userdata is intact before the redirect. The session had my email information, group information and $identity_column information.
However, after the redirect, the session data is empty on some IE7 browsers, which is why CI keeps booting me out of the system. It's fully intact on other IE7 browsers and always intact in Firefox.
Why would session data be browser dependent?
Any ideas on how to troubleshoot this further? I am baffled...
It is a frustrating problem with the Codeigniter database session class, in the end I resorted to using native sessions using the drop-in replacement found here: https://github.com/EllisLab/CodeIgniter/wiki/Native-session
I was having the same problem while using CI Session in IE. Then I use the below header in controller constructor and it works for me.
Here is the header:
header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');
I faced the same problem while using IE8 with browser mode. I've found the problem is in matching the user agent. In session database it saves useragent as IE7 but from cookie it gets IE8. I've set $config[sess_match_useragent] = FALSE and the problem is solved.
The session class works fine in several of my projects including IE6/7/8 support (including multiple releases of CI). There are a few things that might be causing this, outside of the code pasted above:
Calling $this->session->sess_create(); from a baseclass (or elsewhere in your class's code) would reset your session.
Try combining your set_userdata calls to one call by passing it an array.
Make sure your data does not have any unexpected characters in it (this can cause issues in certain browsers).
Make sure your session class settings in the config are not rolling over the cookie every request.
Alternatively, consider an alternate session class like Native sessions
This is an issue that someone made a 3rd party fix for, it patches the session controller. Let me dig it up. I have used it in my codeigniter setups since it was first noted.
This issue is IE7/IE8 specific with redirects or frames.
EDIT
Here is the reference that I have found before, it helped me with the IE issue. Hopefully this is what is causing you headaches:
http://www.philsbury.co.uk/blog/code-igniter-sessions
It's a problem with browsers. I put this in MY_Controller in constructor:
header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
for example:
if($this->uri->segment(1)=='admin') header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
We were developing an app involving a Facebook tab when we ran into this problem. We tried the above to no avail. Here's what we found out:
IE privacy settings seem to have to be medium or less
If your running a page app, make sure BOTH URL's have HTTPS protocol in them
Also, look into the Compact Privacy Policy for cookies.
config file application config.php
// 'cookie_secure' = Cookies will only be set if a secure HTTPS connection exists.
$config['cookie_secure'] = FALSE;
I solved this by using native php session instead of cookies (Storing codeigniter session_id in php native session).
You can grab library here: https://github.com/staskus/codeigniter-2.--native-session.
Just copy MY_Session.php file into applications/libraries
The problem is IE denying the cookie CI is trying to set. Native sessions is one way, however if you want to keep using CI sessions I have had success with the following troubleshooting:
Check that setting $config['cookie_domain'] in config.php is not empty
Remove the underscore from $config['sess_cookie_name'], for example change "ci_session" to "cisession"
Check that the server time is correct
I hate IE !!!
its working now giving P3P to our controllers fix the problem :
class Chupacabra extends CI_Controller {
function __construct() {
parent::__construct();
header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');
}
This issue plagued me when I was trying get a login page to work in CodeIgnitor. The session would not save.
It turns out that it was due to a domain name that I created from FREEDNS that contained an underscore (_). I renamed the domain name using a period (.) and reverted all the code changes that were suggested in this post, and Voila, it worked.
Thanks for all the comments and contributions on this page because they really led me down the road of investigating that darn underscore.