Accessing Joomla Cookies via Sub-Domains

 

 

The solution is to set the session for your whole domain and/or site. It applies if you’re trying to access the session data outside of joomla scope. For example, if your joomla site is located on http://example.com/joomla/ and your other site on http://othersite.example.com/ then the cookie holding the session id is not transmitted from joomla to the other site. To modify this behaviour, use session_ set_ cookie_ params before every session_start() (I don’t know joomla very well, but you should have to add only a few lines of code). Use it this way:

session_set_cookie_params(86400,'/','.example.com');

86400 is the lifetime of the session, set it to what you prefer (86400 is one day). ‘/’ is the path of the cookie. It means that if your joomla site is located on http://example.com/joomla/ , the session cookie will still be sent if the user accesses http://example.com/ .

‘.example.com’ is the domain. Note the dot at the beginning, it’s very important. It says that the session cookie will be sent on any subdomain of example.com. If you don’t put it, the cookie will be sent only for addresses starting with http://example.com/ .

This should solve your problem, unless you are trying to access the session data from another domain. If it’s the case, leave a comment here, I’ll see if I cand find something.

Parallels Fedora F17 KeyRing issue – Please enter password for login keyring FIX

 
 
It seems that when you install Fedora F17 from the Parallels Store it will setup your keyring password as ‘parallels’, which will be different than the login password that you will have created when you setup the system.
 
In order to fix this you must go to Passwords and Keys,
 
Click on  View -> By Keyring
 
Choose the Login keyring, right click -> Change
 
Then enter the ‘parallels’ as the password and change this to a password of your choice. Perhaps a good idea to keep this the same as your login password if you are doing development, testing and if you have a fairly strong password that is not likely to be guessed. Best practice would recommend that you have seperate password for keychain and login, but this is not always practical if you’re doing local development.
 
Hope this helps.
 
Enjoy!

Securing SSH, SSHD CentOS 5, CentOS 6

By default, ssh listens for incoming connections on port 22. For a hacker to determine ssh is running on your machine, he’ll most likely scan port 22 to determine this.

To make the change, add a line like this to your /etc/ssh/sshd_config file:
vi /etc/ssh/sshd_config
Now change the list Port to anything you choose, except a port that is reserved for known services.
Port 23145  #Change me

Enable Root SSH Login CentOS 5x, 6.x

Enable Root SSH Login CentOS 5x, 6.x

SSH server settings are stored in the /etc/ssh/sshd_config file. To enable root logins, make sure you have the following entry:

# Enable root logins:
PermitRootLogin yes

and restart the sshd service:

service sshd restart

If you need root access, login as a normal user and use the su command.