For some reason I can no longer post a comment as an Anonymous user in my Drupal installation. I haven't tried in a while, so I'm not quite sure when this functionality was broken.
I have Services installed, and I can post anonymous comments using comment.save. I have altered the Input Formats if that could break something.
I have enabled both post comments and access comments on the anonymous user. The comments does not show up in the database. In fact, the native Drupal function comment_save isn't called when I try to comment as Anonymous (I check this by adding print_r($edit);die(); at the top of the comment_save function in comment.module. Also I read something that not having a User with the UID 0 would break the Anonymous commenting, this user exists (obviously, since commenting through Services works)
I have tried out the AntiSpam module, and posted a comment as Anonymous that would get caught(and did) in the spamfilter, but this module is now disabled.
I'm really running out of ideas here, does anyone have any other suggestions on what to do? In the meanwhile I'm going to attempt to backtrack the code to figure out why comment_save() isn't being called.
Edit: Anonymous users also don't have to submit email and such to post, if that matters in any way.
By what you say, I suspect the problem is with some contributed code hooking on the comment form and modifying it in a way that makes it fail submission. This can be caused by a number of causes: a jQuery that adds fields to the form without regenerating the form-id on the server, an added or cusomised field that changes the callback to submit the form, etc...
I cannot know it for sure, but here's what I would do if I were you, in order to check what's up with your installation:
Make sure you disinstalled (and not only disabled) the modules you tried and don't use anymore. Modules should never touch core tables, but who knows... It does not cost anything and it actually frees some of your DB.
Try disabling all contrib modules and see if you can comment that way. If this is the case, activate the contrib modules one at a time until you find out which one is the culprit. Chances are you will already find a patch/workaround in the issue queue for that module on http://drupal.org. If you don't find a fix, I would investigate (xdebug or manual tracking) the code, and I would pay special attention to all implementations of hook_form_alter() and hook_form_FORM_ID_alter().
If even disabling all contrib modules doesn't help (which I would be very astonished of), try updating the core with a fresh installation if you consider as a possibility that your cat walked on the keyboard while you had a core file opened, or you live with Gordon Brown's family.
Failing that, the only alternatives coming to my mind are much more esoteric, such DB failure, a greasemonkey script on your browser interfering with commenting and similar unlikely possibilities.
HTH!
I solved this once by resetting the permissions table (http://drupal.org/node/64114), but I would do a proper backup and keep the permissions page open in a tab, just in case.
Related
I have a running Kentico 11 portal engine site and need to update the transformations in my navigation menu control. Something I have done many times before.
Today I went through all of the steps and the save button does not update the code. It never displays the change were saved messaging.
When I open the browser dev tools I see several errors on the page:
errors
A couple of things to check.
Is this happening in different browsers, also?
Can you save other transformations?
On this particular web part, if you select a different transformation, will that save successfully?
And, is the event log registering any errors?
Sounds like it may be a caching issue. What I'd suggest is the following:
restarting IIS
Open a private browser window and log in
attempt to make an edit to the code in question
If this does not resolve the issue, have you made any changes recently to the web.config, in particular the CMSHashstringsalt value? If so, this will cause your macros to become invalidated. You'll need to go to System > Macros > Signatures and check both boxes and resign the macros. It may take some time depending on your site but this could also help resolve your issue.
I ran into some trouble modifying my product and reinstalling it, so I tried installing the version I know works on my live site.
Still no love, just an error message I can't decipher which seems to contain spam! Any suggestions as to how I can diagnose this or where to seek help?
This pastie has the error, truncated due to size:
http://www.pastie.org/2715995
Come to think of it I did see an unidentified user listed at one stage...
Thanks!
Most likely, your site has been compromised by an automated script exploiting CVE-2011-2528. The script adds accounts, changes passwords of existing accounts, and customizes your main_template macro.
In order to clean this up, you need to:
Install the Plone Hotfix.
Reset your session secrets to prevent reuse of old session cookies the attacker may still have.
Audit the accounts present, removing any you do not know, especially if they Administrator access.
Clean up your main_template macro. If you never customized it through the web, simply delete it from your portal_sites/custom folder (go to the ZMI, select portal_sites, select custom, and delete), otherwise edit it and remove the hidden links at the bottom.
What I did
Let's say my module was called "some_module". Without disabling from the Modules menu, I renamed that folder and changed the contents, now it's "another_module". I perceive that the site is slowing down, trying to still look for "some_module".
What I've tried and expected
I've tried clearing the cache a few times, expecting Drupal to rebuild it's module list based on what's available. However, I'm not sure how the inner-workings of enabling/disabling modules works, and I don't know if my site is still going slow because of this reason, or for another reason.
What I found in the documentation
I read some of the documentation on Drupal Modules, but it looks like there are some pretty simple functions like module_exists(), but it doesn't describe whether or not it will ever stop looking for "some_module".
My question
So, my question is: have I left behind bloated garbage that is slowing down my Drupal site by not disabling the module before renaming it?
And a bonus question...are any of these documented benchmarks applicable to this situation?
Drupal will keep on looking for that module while there's still an entry for it in the system table. Delete the entry from there, delete any tables that your module created, then clear your caches. It will be as if the module never existed so if you still perceive your site to be slow at that point you know that the old module meta data was not the culprit.
How to rename drupal's admin directory as I already have a directory named "admin"?
As Bleadedu pointed out, Drupal has no "directories" in its URL.
The urls you see are all so called "clean urls", achieved with a nifty trick in Apache (the webserver)
configuration. You could disable clean urls that will fix your problem, but may not be an option, if you rely on this feature for some reason.
Another option is to use path module to circumvent this issue. This has downsides too, most notably, the fact you need to manually change each url with admin in it.
The last option is to change the rewrite rules in Apache. This is hard to achieve and requires some knowledge of mod_rewrite.
you can't. simply because admin directory doesn't exist. it's just a url path (defined in all modules that have got a reference of it in hook_menu)
The only solution I have right now is to implements hook_menu_alter and redirect all menus that starts with admin/ somewhere else, but I can't say that it will work 100%.
Instead of changing the path of /admin, you should beef up security elsewhere.
First, finding out your site uses Drupal is a piece of cake.
Huge companies use Drupal, and don't change their /admin path.
Don't use User 1. Most of the time, there is no need for anyone to be using User 1. Even the highest of admins should be given a role, and certain permissions. User 1 should have a complicated long password, changed every (x) number of days or hours, but never actually used. I think there is also a module for this, but I can't remember off the top of my head because I just do this programmatically.
logintoboggan.module
The Login Toboggan module will display the login form for Access denied pages
login_security.module
protect_critical_users.module
userprotect.module
session_limit.module
nodeaccess.module
Don't let direct access to update.php and cron.php. Create a cronjob to run via shell.
-have them direct to forbidden/or a 404 with a search page
Use the tools in cpanel/whm or similar. Knock out bad login attempts and such.
There are a ton of other ways to beef up security in drupal.
I somehow forgot that you said "as I already have a directory named "admin". opps.
I think you would be wise to either alter that other directly instead, put it inside of another directory, or simply don't use it.
It is just going to be very messy. You would have to look into every single module to see if it needs adjusting.
Off the top of my head, the user.module will need to be altered, and also take a look at http://api.drupal.org/api/search/6/url_rewrite.
custom_url_rewrite_outbound and custom_url_rewrite_inbound will work, BUT you will still be able to access /admin by typing it in manually. You will get a forbidden if you stick a "admin" folder in your root.
All in all, I think it would be a messy venture, and you might get a lot of broken updates. Until something like this is offered in core, I wouldn't do it. Even if there was a module that could, I wouldn't use it.
*You will have to "Hack Core," and I don't think this justifies hacking the core.
I have an incredibly frustrating problem cleaning up my site at the moment. On the same hosting space I have Umbraco (ASP.NET) and Blab Lite (PHP Chatroom) installed. The former talks to SQL 2005, and the latter to MySQL 5.
On my Umbraco site I had a guestbook with an entry form. Upon postback it does an Akismet check and skips the creation/saving of the corresponding Umbraco document if it is verified by Akismet as spam.
However, recently I started getting entries created under my guestbook node which are verified as spam, and yet the document is still saved. I have even gone as far as hiding the form using "display:none" and yet these entries are still created! I have modified the DLL to include logging to Umbraco document event logs and somehow the creation of these still does not trigger any entries to the logs. I've even created an eventhandler for Document.BeforeSave event in a separate assembly and this event handler is not catching the saving of these entries.
I'm really stumped as to how the spammers can create these entries. Has anyone got any ideas how this can be done, and how I can secure my site to prevent this kind of attack?
Thanks,
Dany.
This seems like an old post but it's not marked as answered so I'll give it a go. I havnt used Umbraco in a while so I'm not sure if they've fixed this in the latest version, but the problem is with Umbraco it self. Document.BeforeSave() gets fired AFTER the node is created, that's why your spam filter is not working. Marking the form as not visible wont work because the bot will look at the source code and just pattern match the form fields it finds. Have a look here for more details on the Umbraco problem:
http://forum.umbraco.org/yaf_postst9312_BeforePublish-and-BeforeSave-Event-Handlers.aspx
Like I said I haven't used Umbraco in ages, but hopefully it will help someone even if you've found a fix.
Paul
My guess is that there is a bug in your code to skip the creation/saving of the Umbraco document... although it is strange that the Document.BeforeSave event is not triggered. Are you sure that your event listeners are also working (i.e. do they register the saving of non-spam entries?)
By the way, setting "display:none" won't stop spammers as bots will generally ignore CSS anyway.
Yup, the event listeners are working indeed. This lead me to think something else is odd here. I finally took the plunge and went through it all with a finer-toothed comb. First I compared the content of the bin folder between standard Umbraco 4 distribution and the one on my host. I figured it was easiest to overwrite each one with a fresh one. Then I went through each Umbraco package I've installed and made sure the DLLs are also fine. Well, there was 1 DLL that didn't match anything else in Umbraco or packages I've installed - EO.Web.dll!
It seems there's a legit thing out there by EssentialObjects but I don't think Umbraco, my code, or any of the packages actually uses it! I deleted it and every part of my Umbraco install still works! I've now set visibility of of the form in ascx markup so it's not rendered - now we wait and see if that was the offending piece of malware!