session

  • This warning message is produced by PHP if a program attempts to send an additional HTTP header after the separator (and hence all the headers) has already been sent. In the HTTP protocol a server response consists of a group of headers followed by a body, separated by a single blank line (i.e. a line containing only a carriage-return).

  • Cross Site Scripting is a hacking technique whereby malicious scripting code (usually javascript) is injected into user input forms (in a similar way to SQL injection attacks) or incorporated in a URL query string.

  • A Cross Site Request Forgery (CSRF) attack relies on the trust a website has for a user to execute unauthorized requests and or transactions. For example, say a user is logged into their Joomla! websites' administrator interface in one tab and is browsing a compromised site in another tab.

  • Full Path Disclosure (FPD) vulnerabilities enable the attacker to see the path to the webroot/file. e.g.: /home/omg/htdocs/file/. Certain vulnerabilities, such as using the load_file() (within a SQL Injection ) query to view the page source, require the attacker to have the full path to the file they wish to view. Then the attacker can use this info to perform other type of attacks based on the obtained information.

  • Sometimes, if more people work on the site, you can get locked out of a certain module or article because the site thinks someone else is still editing that item. When opened, each Joomla item is checked out, this way Joomla protects each editable item from being edited by two separate users at the same itme, and this way avoiding potential confusion and other obvious problems.

  • Time-to-time I am hitting the wall with this, even with 100+ VM sites in my portfolio, and parts of VM core having my signature. Here are few tricks wich usually solves the problem.

  • It is an error which drive me crazy couple of times. It's easy to fix - but hard to detect why happening. I didn't see any good explanation which fits to each single situation I needed to handle it. There are couple of popular theories on what causes the "jtablesession::Store Failed - DB function failed with error" type of errors, but sincerely  I can not confirm any of them:

    • Flooding (Check your http access logs for access IP’s, and your PHP error logs). Solution: Try dropping the time out down temporally to a lower value, to see if the sessions clear or not.
    • SEF If your site has a lot of visitors table jos_session can accumulate substantial overhead. And if you use default SEF, some 404 pages can make some bots to enter into loop, and those bots gives you a huge session overhead.
    • Site statistics from within Joomla. Enabling statistics through your site configuration just adds extra MySQL queries and increases server loads.
  • As I write this, both Joomla 1.5 and 2.5 have reached their EOL (End Of Life) for long time, and are not developed or supported anymore. This is a huge security risk, so the best advice here is to upgrade your Joomla site to the latest version. But what if you don't have the time/funds to do it right now?

  • Sometimes when you publish a new menu item, and everything seems to be OK, when you try to access the new menu item you just created you hit the wall: instead of the intended content you'll see the following error:

    You are not authorized to view this resource.
    You need to login.

    Even more confusing can be the situation when a link which used to work behaves this way. The target content item is published, access rights are set to Public, and you still got this message! What can be wrong here?

  • It's annoying... your own Joomla site don't let you log in in the backend, and you see the above error message... What's happened?

    Humm, there are couple of things you can do. Contrary of the lots of "smart" blog entries on the subject out there (last search revealed about 2 million hits) in most of the cases, regardless to Joomla version the cause is simple: