I am using version 2.1.3 of CodeIgniter, and primarily use Chrome or FireFox, but I am learning that some of my clients are having issues with my systems not allowing them to log in. The system log indicates that the user has logged in, but I check if the session variable is set to determine whether the control panel or login screen needs to be displayed.
For some reason, the session variables are not set in at least IE8 and below, so the login screen keeps showing, even though the log says the user is logged in.
I checked this: CodeIgniter IE not storing sessions correctly and this is not applicable to me.
I am not using Ajax for this, so this is not it either: PHP Session lost in CodeIgniter IE only
Also, this is not loaded in an iFrame. So, I doubt there are P3P problems: CodeIgniter 2.x sessions and Internet Explorer
What could be the cause of this?
Thanks!
I could just guess, hope its helpful.
Check your php files if you have a closing tag ?> and if you have a whitespace after it. This cause to return a blank response, because of the whitespace, and this breaks the session and cookies.
Do you have some mechanism for regenerating session id`s
Thats all i can come up with, hope i`ve helped.
Regards
I found this article, and it appears to solve the problem for me, but I want to test more before accepting my own answer.
http://ellislab.com/forums/viewthread/211955/#982986
Hope this helps someone else.
Regards,
Kobus
Related
I am in the process of building a shop on wordpress using woocommerce. All is well except that at checkout there is an endless spinning wheel blocking the payment processing.
I have checked the error logs - which show no errors
I have disabled all plug ins - which makes no difference
I have reverted to the default woocommerce shopfront theme - which has the same result.
The console shows no errors.
I have also followed the instructions here https://docs.woocommerce.com/document/endless-loadingspinner-on-the-checkout-page/ which assumes its a memory limit issue. This did not work.
So, after a bit of digging I found some reference here https://mikejolley.com/2015/11/12/debugging-unexpected-token-in-woocommerce-2-4/ and here https://www.maxsangster.com/blog/woocommerce-endless-loading-spinner-on-checkout/
Referring to these two pages I have been able to see that the json response from /?wc-ajax=checkout is just returning HTML which I would imagine is where the issue is.
However I am running an Apache server rather than Nginx as has been mentioned in some threads and articles. Assuming there is a server misconfiguration of the server or something that needs changing what might that be? Bearing in mind that I do not have direct access to this, so will need to be asking someone else to sort it out for me.
And finally if there is something else I can try what might that be?
Thank you to #plushyObject for generating the spark for this one.
The issue turned out that I had a legacy static html holding page in place as the site's homepage rather than having one set up with wordpress. Simply removing the .html page and letting wordpress's homepage take over solves the problem.
The moral of the story create your holding page in wordpress.
Go to Google Developer Tools, then Go to the Network tab. Click the button and make the request and let that bad boy spin out.
You mentioned the response is returning HTML. Click on the request that goes out that appears to be taking forever (/?wc-ajax=checkout) and then click on the Preview tab to display that HTML. I bet it shows an error or a clue, anyway.
In my case the checkout was working fine on Desktop but not on Mobile. After many search on internet I read the solution of #UntitledGraphic.
I had set a redirect in ht-access. The redirect was showing a different home page for mobile. When I removed it, the error gone. I checked back & forth and was sure the ht-access redirect was the problem.
If you have set any redirect in the Htaccess then remove it. This will solve your issue in this case.
I also checked the redirect code on function.php instead of htaccess again the problem appeared. So finally removed the redirection.
In my own case the redirection was the issue. So I had to delete the redirect I created via Cpanel.
Here's the "long story short" version of my issue:
I have this newsletter/subscription form that triggers the wp-admin/admin-ajax.php file, however the form wasn't working when I wasn't logged into Wordpress.
Turns out, the admin-ajax.php file has a 302 going against it.
I have already seen/tested previous resolutions of this problem (namely this one and that one), however none of them were helpful.
I searched throughout my theme files for any related "wp-admin" protections, I didn't find anything.
I modified and deactivated both WP Better Security and W3C (as well as various other plugins), nothing changed.
I changed/removed the htaccess, nothing changed.
I'm kind of getting frustrated with this issue.
At this point, I know there's somewhere in my code something blocking access to admin-ajax.php for "outsiders," however I can't figure out where.
It's either something protecting my admin folder and/or something protect admin-ajax.php.
Any ideas?
Help would be much appreciated.Thanks in advance!
Ok, the problem here is that Wordpress uses two different hooks for ajax. It uses one for admin side, and one for logged out user. My guess is that your form is not using the latter.
Have a look at the two:
add_action('wp_ajax_my_action', 'my_action_callback');
add_action('wp_ajax_nopriv_my_action', 'my_action_callback');
From Wordpress Codex:
Since WordPress 2.8, there is a hook similar to wp_ajax_(action):
wp_ajax_nopriv_(action) executes for users that are not logged in. So,
if you want it to fire on the front-end for both visitors and
logged-in users, you can do this:
add_action('wp_ajax_my_action', 'my_action_callback');
add_action('wp_ajax_nopriv_my_action', 'my_action_callback');
See here: http://codex.wordpress.org/AJAX_in_Plugins
This is a very strange one for me and I've been battling with it for a while now. I really hope someone can help.
I have a fairly typical MVC 3 Website and I only seem to be getting this problem in IE and Firefox. Chrome plays along nicely. Lucky for me, the majority of our company's clients uses Chrome at the moment.
Problem is at a seemingly random point in time, the browser will automatically redirect me to the Account/LogOff action when I click on a link, and from there it will obviously go back to the Login page. This link will then continue with the same behavior.
I say "seemingly random" because today that link will work, tomorrow it won't and all other (or the majority - I have never had more than on problem link giving this problem at a time) links will be fine. Sometimes restarting the server/dev environment will take care of the problem, other times it won't. The browser will just keep redirecting to LogOff.
I have tried looking at the Referrer URL, but the controller/action being referred to will never be reached. (If I place a breakpoint in the action, it is missed and the next point reached would be the LogOff action)
If I look at the stacktrace when in the LogOff Action, I can't see any info from where the application has come from. I have also tried what was suggested in this page: Posting the Stack Trace on ASP.NET MVC, but I cannot see why I am being redirected to the LogOff action.
The only place I seem to be able to have a breakpoint get hit before hitting LogOff, is Application_BeginRequest in the Global.asax, but can't see where it is going from there on.
My guess is that somewhere along the line, ASPNET Auth decides the user isn't authenticated any more and redirects to the LogOff action. Problem is that the cookies associated with ASPNET Auth all still exist, have data in them and they haven't expired yet.
Anyway, I hope I have given enough info on the problem.
Thanks in advance.
[Edit]
OK, so I might have gotten a step closer. I came across this link and looked to see what is happening in my Application_AuthenticateRequest in my global.asax.
I am not quite sure why, by when I click on a link, Application_AuthenticateRequest gets accessed 3 times. When a link works (as in I can follow it and it doesn't log me out), the value of the .ASPAUTH cookie stays the same. I checked this by adding a breakpoint and a watch over
HttpContext.Current.Request.Cookies[".ASPXAUTH"].Value
When the link does not work, the first time the cookie has a value, then the other two times it is null. Thus, because the ASPXAUTH cookie is null, the system automatically redirects to the LogOut action.
If I consider the solution they posted in the link, I am not sure if this applies to me. As far as I can tell, the encrypted cookie is still small (as in a few hundred characters long) and not close to 4096 bytes. Also, I have only 3 cookies going at the time I when tested the broken link and I have a maximum of 5 cookies at any given time.
Any idea?
OK, so I had a hunch about cookies expiring. So I looked at whether there is a way to keep (force) cookies in Forms Authentication alive and that led me to http://www.codeproject.com/Articles/221889/How-to-Generate-Machine-Key-in-IIS7
The only way I could test this theory was to keep working and debugging the site as normal. (And that's why it took me so long to post this answer.) Since I introduced this solution it seems that the problem has been solved.
Interestingly I spoke an Architect the other day, with 20 years dev experience, about my problem. He looked at my code and is convinced this is a bug in the Forms Authentication code.
I hope this helps some people who are experiencing the same problem I have.
We are having an issue with logging in a second time on our site ever since we installed the lightspeed module. At first I thought this might have to do with the need for hole punching, but now I'm not sure.
If you try to log into our website the first time, it works well. However, if you log in a second time, it won't work. It just remains on the customer/account/login page with no effect.
I tried to test this on my end, and echoed the user's email in the loginPost function in the account controller. When echoing directly from the controller, it was obvious that the user was being logged in, but upon the redirect to a page on the site, the user was no longer logged in and appeared as a Guest in the Magento backend (where you view online customers).
It appears to me as if the session is being lost after the redirect. I am not sure if this has anything to do with a switch between https and http as described in the stackoverflow problem here (http://stackoverflow.com/questions/7823994/magento-session-lost-when-switching-to-https-from-http ) where they had also installed lightspeed. The person there resolved the problem, but did not post the solution. Their problem wasn't the same as ours, but I was thinking there may be a connection between the two.
Has anyone seen a problem like this before?
Thanks in advance,
Brenda
I've got a web service that, like most others, uses js and css files. I use the old trick of appending a version number to the js and css file like; ?v=123 and that gets changed every time we update the service on production.
Now, this works fine on all browsers, except for Chrome. Chrome seems to prefer it's cached version over getting the new one and therefor seems to ignore the appended variable. In some cases, forcing it to refresh cache (cmd+r / ctrl+f5) wasn't enough so I had to go into options and clear out the cache for it to load up the new content.
Has anyone experienced this issue with Chrome? And if so, what was the resolution to the problem?
Chrome should certainly treat requests with varying query strings as different requests; a cached result for style.css?v=123 should never be used for style.css?v=124. If you're seeing different behavior, please file a bug at http://new.crbug.com/ and post the bug ID here.
That said, I'd first check to see whether the page was cached longer than you expected. If a new version of the page itself wasn't downloaded, then it would still be requesting ?v=123 as the HTML wouldn't have changed. If you're sending long-lived cache headers with the page, it's certainly possible that Chrome is caching it more aggressively than you expected. If that's the behavior you're seeing, please star http://crbug.com/8742 for updates.
I had also same experience
You can user Ctrl + Shift + R for cache free browsing in both Chrome + Mozilla.
I have had this experience as well.
I run a membership site which displays content such as "You must be logged in as a Gold member in order to see this content" if they are not logged in or are trying to view content not allowed by their membership level. But even if the user is logged in, the user would still see "You need to log in", due to Google Chrome's aggressive caching. In Firefox, however, it works fine as I test logging in and out of all 5 levels of membership - each displaying the proper content.
While Chrome's caching problem can be solved by clearing the cache every time the user logs in and out, it would be really annoying to take that approach.