I have actual the latest TYPO3 6.2 version ... 6.2.31 ... I know ... working on upgrade.
But now I have a google hack which replaces Links in Google with Viagra stuff. Had this several weeks ago thought I fixed it with update from 6.2.9 to 6.2.31
There is unkown code in Core .. Does any Body knows this and can help me fix the hole?
last time it was here:
/data/www/domain/public/typo3/typo3/sysext/cms/tslib/index_ts.php
Thanks at all
Please follow the TYPO3 Security Guide which means that if your website is hacked you must take it offline, check the site, find the security issue and then bring it only.
If your website is hacked, not only your server and data is at risk but every user who visits your website. Especially if users trust you and your knowledge, you should take that issue serious.
Most of the time I have seen this issue one of the following problems occurred:
Hacked FTP account
Security issues in custom or 3rd party extensions.
Related
I am using PrestaShop 1.7.5.2 and recently changed my server & now the problem is that in my admin few pages are not working like "Products, Invoices, Stocks, Module Manager, Module Catalogue, Theme Catalogue etc.
My front end is working fine.
I have read almost all the content available but was not able to find exact solution to it.
Any help will be highly appreciated
Thanks,
GC
Edited just now by gauravchawla18 (see edit history)
Your database is incomplete. At least ps_translation table is missing.
Please check your database import.
I have a problem whose solution is certainly very simple, but it does not come to my mind at the moment :/
I have a multi-domain TYPO3 (6.1) installation and in one of the websites I need to temporarily show only one subpage, and over the rest of the pages I will work/update so I can not delete them. It is important that someone after entering a URL or going to the page from the Google search results has not opened this page, and has been redirected to this temporary.
I've tried the mount points but something does not work ...
Please help.
You can exchange the domain-records.
Make a new page on it's own (independent from the configuration of the domain it should replace). so it is a root-page. give it a domain record and disable the domain record of the pagetree it should replace.
Be aware to change the rootpageid configuration in realurl.
You also may need a special configuration for 404 handling for this domain as the most requests will be a 404 (or better 503).
And hurry up to update your system. TYPO3 6.1 is out of service for a long time.
Since version 3, plone.protect provides automatic CSRF protection.
Plone 4.3 includes, by default, plone.protect 2.0.
Can I just upgrade to start using this feature in Plone 4.3?
I have only a little experience with it and played around with plone.protect 3.x and Plone 4.3.2, but nothing serious.
I had also a lot of addons installed, so I cannot say if there were problems with Plone itself, or an addon.
Here are my notes:
Yes you can enable it, but your installation will stop work.
So... No you cannot :-)
First plone.protect.aut 3.0 handles every POST/GET request by default.
For example Session handling is a write request, so you have to fix this manually wherever it's in use!
Second writing data in annotations (IAnnotation), it's also protected by default, so have to find every place where annotations are used (For example Portlets storage) and fix it.
If your testing environment is in a good shape :-) you will get it work, but out of the box Plone 4.3 is not ready to use it.
Conclusion:
The main problem are GET requests, which ends up with a database change.
I now this is wrong but Plone 4.3 and/or mainly the addons have this behavior.
You will end up in extending the plone.protect.auto feature by a whitelist.
I wrote all the auto-csrf stuff. I would recommend against using it in Plone 4 unless you want to invest a lot of time into it.
Easiest way to fix using it on Plone 5 would be to add in some javascript that automatically protects almost everything for you when logged in. That won't deal with ZMI and then it depends on javascript to work.
JavaScript would do a couple things:
add the authenticator token to all forms that post back to the site
add the authenticator token to all admin urls that potentially do writes to the database. For instance, the "Edit" button does a write to the database because in Plone 4, AT Content Types makes a temporary object in the database. Also, it writes with locking support.
add authenticator token to all ajax requests. Use something like https://api.jquery.com/ajaxSend/ to add the token.
I have installed SilverStripe on several servers successfully in the past (but I'm not a SilverStripe expert). This time my SS install fails to work and I'm at a loss how to fix it.
The Problem
SilverStripe 2.4.6 installed correctly on the server (AFAIK).
The front-end works as expected. (Show default theme. Pages all load correctly.)
I am able to log into the CMS admin section succesfully. The CMS loads but when changing site pages in the CMS using the browser pane on the left, the CMS shows the circular loading symbol. The new page load never completes.
Using the console of Firebug in Firefox - When attempting to change pages in the CMS (by clicking on the page browser pane) the CMS tries to load two pages. The second page request 404s.
The first GET request is from the initial page loads.
The following POST+GET requests fire when clicking on the page tree to change pages.
Attempting to Find the Solution
I've tried deleting and re-installing silverstripe twice. (2.4.7 and 2.4.6) Both times the problem recurs.
A strange thing is that this server is already running two other silverstripe sites (both of which I installed without a hitch). All three websites are accessed via different domains. I tried accessing this install via another domain thinking there might be something wrong with how this third domain is configured but that didn't help either.
What should I try now? I'm stumped.
Thanks in advance.
Responses to Comments
Check your root .htaccess file. Make sure RewriteBase is set to /
Checked. Full .htaccess on PasteBin
Indeed the javascrip URL is strange. Check if there is anything unusual about what's being returned from the previous POST request. Is the site running in dev, test or live mode?
I can't see anything unusual in the POST request.
Clue Found: The site is running in DEV mode. Switching to LIVE mode and the problem disappears. Also the second GET request only shows up in DEV mode.
Example Post request with response.
Example Get request with respones.
This is a work around more than a fix but if you'd rather be coding than bug hunting it might be worth a go! (remember to log out of SS before doing this fix)
In your mysite/_config.php file change
Director::set_environment_type("dev");
to
if(!isset($_GET['isDev']))
Director::set_environment_type("dev");
else
Director::set_environment_type("live");
Then you can develop the website in dev mode normally and to use the admin in live mode and avoid the bug you just go to: http://{your_domain}/admin?isDev=0
N.B. might find a proper answer when pastebin.com isn't overloaded and I can see your responses!
I am using the Magento ver. 1.4.0.1 Community Edition. The problem I am running into is that Magento only allows me to preview pages that I have already saved. This works fine if I am creating a new page - but what if I am editing a current page? I want to be sure that the changes I make look good on the site before saving them.
Does anyone know of a way to preview a static cms page before saving the changes made? I'm open to using some sort of plugin if anyone knows of one.
Thanks
Currently there isn't one in Magento, you'll just have to save it and view it.
A lot of the work I've done in Magento has been done on a development server, once everything was set it got moved to the production server. I'm not saying you need two servers, but having at least a development instance of Magento will help when editing a live site.
for non-trivial changes, I normally create a new page with a URL that's not linked anywhere and then load that up to preview, before copying the content/settings to the real page.