I have a drupal site connected to another non-drupal site. (All php) They have Single sign-on. Some info is stored in a cookie. So when a user signs in in the Drupal site and clicks the link to the other site he is automatically signed in in the next site. The new (or existing) user gets generated (or updated) automatically every time.
Now the problem:
Somehow some of my changes to a couple of pages regarding this authentication are ignored when I use the HTTPS:// link. It looks like it keeps checking the old files... Like they are stored in a hidden place? When I change to HTTP:// suddenly it takes the new modified files...
And it only happens to files about the authentication process. All my other commits to other parts of the second website work like normal. Just these couple of authentication files get ignored.
Does anybody knows why https behaves like this?
Could this be server caching or php caching ?
I'm going to post the answer to my own question so hopefully I can help someone else with a similar problem.
There were 2 files with the same name.
The HTTPS login file was in the private_html folder.
the http login file was in the public_html folder.
They both had the same name. So when I updated the http file and pushed it to the server, the https login file stayed untouched. And since the https login file was not in the git repository I couldn't find it locally, but only on the server...
Problem solved, so no caching problems at all.
Related
I have this script that works well on other servers but the session part fails on a particular host. I have pointed to another server but would really like to figure out what could be the problem. I have observed that :
It takes 5-15 mins for changes on code to reflect(e.g changing
text on index page).The server seems to cache pages especially index
(BTW i cleared my browsers cache e.t.c)
When i logout and login as another user the server still retains
the session of the last user on the index page (the other pages seem
OK)
I can open index.php (without logging any user) and what i
believe is the last logged in users details display
I tried swapping my code for some authentication systems on github (just to be sure) even PHPAuth which uses cookies (not sessions) fails the same way. But the same code works flawlessly on localhost as well as other servers.
So i would like to figure out exactly what goes on on that host. It is a shared hosting package.
Got a reply from the host. Seems the problem was with the hosts session variable path. They fixed it.Thanks
The problem is that I have made a wordpress site on localhost, than I have copied everything to a 000webhost.com domain, changed every post and page IDs, but the site doesn't work on the domain after I log off my wordpress account.
The site has language change option which is works with a languageID cookie (value is 0 if english, and 1 if hungarian). I click on the flag of the language, the cookie value is change properly and the site language too, but when I load another page, the language stays the old. The page sees the cookies (I watched it in the Application->Cookies menu), and after a hard reload, the language changes. The path is / and I gave an expiration date too.
The other strange things is that if I overwrite the header.php file, the header won't change its contant on the pages exept the front page.
I can't upload the site's files cause they are very huge, but I can tell more things that could help you to solve my problem:
The pages have their own .php files with their slug (like page-some-slug.php)
The permalinks are like www.mysite.com/pagename
Everything works fine on localhost with or without logged in with my wordpress account
I have changed only the page and post ID-s in the code
I have changed the header.php files, but the header on the pages didn't changed even after hard reload the browser
If you could help, please help me!
As you mentioned that the WordPress script worked in your localhost and now it's not working on 000webhost.com a free web hosting services? right?
The issue is the free web host, They have restrict free users access for limited feature.
Maybe they don't allow .htaccess and session creation.
Most things are restricted, if your script works on localhost sure it will work live server. You need to get a paid hosting to unlock all the features.
You can confirm with the 000webhost.com, what are they restricted with free hosting users.
I am really new to Drupal and playing around with this existing Drupal site.
I did a FTP transfer of all the files to my local computer directory. I currently got it on a Vagrant box and I can access the site via http://192.168.56.101/html.
I can do http://192.168.56.101/html/anything-but-user and it brings me to the proper area on the site. However I can't do localhost/html/user, because it redirects me to the website URL rather than the local URL.
I tried clearing the cache (with Drush). I scanned all files in the system and changed the web url to the local URL [not sure if I need to do any other command], and I can't seem to find anything in the .htaccess files that would lead me to this.
The href="/user I would greatly appreciate any advice or help in figuring out this solution.
--UPDATED
There was a module called "Secure Pages" that was causing the user and registration links to be locked and static to prevent redirects to phishing sites. I had to disable this module using "drush pm-disable securepages" in the terminal.
Some typical items you may want to check:
Check if you get the same problem using another browser. If with another browser it works, then it is pretty sure a cookie problem. To solve that, delete the cookie in the browser where you have the problem.
Make sure "clean urls" is enabled. Refer to "https://drupal.stackexchange.com/questions/165029/clean-url-leads-to-duplicate-url-after-migration-to-another-hosting/165044?s=1%7C3.9647#165044" for more details on that.
Make sure the value of "base_url" is set correctly (in your settings.php).
If module Secure Pages is enabled, then try to (at least temporary) disable that moduel to see if it helps.
Apparently, there was a mod called "SecurePages" that was causing the URLs to be static to prevent someone from changing them and redirecting users to a phishing site.
Using Wordpress-Heroku and ran into some issues. Changed my app name from heroku's autogenerated name to something more descriptive, but /wp-admin gets redirected to the old name. Of course there's no such app anymore. Also tried to set up a local version but found that going to localhost:8888/wp-admin redirects me to app on heroku.
I guess that something in the installation process creates permalinks to the site address in the database. Is there a way to fix this without resetting the installation?
I change servers (copying live sites to localhost) fairly frequently following the Codex. While not on Heroku, I assume the process would be the same.
In your case, the Search and Replace for WordPress Databases Script mentioned should do the trick (after backing up the database, of course).
I assume you've updated your wp-config.php to point to the new database.
We built a website for a client using Wordpress. We used a testing server which always works well. Wordpress was hosted as a subdomain, i.e. http://wordpress.ourcompany.com. I have direct and full access to the server. In the etc/apache2/sites-available directory the file describing the site in question uses the final name http://clientsite.com as ServerName, our temporary subdomain (under which we have been building) is a ServerAlias.
When we were almost ready, we of course asked the client (who already had a website) for their domain login. We changed the DNS like always. It resolved, the site worked well. Although Wordpress kept redirecting (of course) to the subdomain-variant, we could enter the site with the full domain.
Now comes the culprit. I changed the Wordpress settings (siteurl and home) to match the new site. The front-end works brilliantly. However, the back-end is unreachable as long as the settings are in this way. The login page shows up, but just redirects back to itself. If I simply change the Wordpress settings (in the options table) I can log back in, but we want to rid the subdomain necessity (of course).
Things I've already tried (I'm not one to easily ask of your time):
Clear .htaccess
Clear my cache & cookies
Different computer, different browser etc.
Change only the home and not the blogurl value. Sadly, this corrupts some plug-ins
Remove all plugins
Comment some lines as instructed in the wp-login file
Naturally, everything I could find on codex.wordpress
Set the admin cookie path
So, brilliant collective mind that is Stack Overflow, what did I do wrong? DNS? Wordpress settings? Thank you in advance.
You need to go into the settings on the live server and change the URL's to the current site. You'll have to do this by accessing the database directly. It's the wp-options table, and there are 2 entries where the url's are the value. Update those. That should fix the looping.
I found an answer today : the user in the database didn't had the right permissions. You can look up in the error log if there are lines that indicates this.
I also had tried before : removing all content from htacess, reinstalling wordpress etc.