support

support@drupal.org

7912 discussions

Drupal File Operations (D715)
by Austin Einter 29 Oct '12

29 Oct '12

Dear All I have some basic question in regard to file operations. *1. file_manage table* Whenever we use file_save_upload api to upload a file, I can see one corresponding row is added to file_manage table. My question is, the row in file_manage table is temporary one or it will be there always. I am planning to read some information from file_manage table afterwards, if it is just a temporary entry, probably I will be in trouble. *2. File / directory permission* My hosting is a linux based hosting. My understanding is whenever a user uploads a file, finally the web server writes the file to system. So the webserver application is the owner. In my case, first I create a folder (with permission 0755), and then write the file (with permission 0664) to that folder. Next time I want to delete the old file and write a new file it is not possible from same user who wrote the file last time or from any other user. Can somebody explain me why the permission issue comes here as always it is the webserver that writes the file, so virtually owner remains same. If I keep the folder permission 0777 then second time file write is possible. And, by keeping folder permission 0777, am I bringing up a security issue here.... Thanks and Regards Austin

2 1

Subject: Re: Site Hacked
by Roger 29 Oct '12

29 Oct '12

> Pl go to drupal support and give your details and report them about > hacking better change admin password No point in doing that. It's a whole of Drupal design thing, including engine and modules. It is not a small problem. The inherent problems, for us, with Drupal 7 are: - The engine is part of the site and can be played with/altered while live. Convenient but potentially damaging. - There is no way to not have admin on a live site. In fact there should be no admin at all on a live site or as a minimum, a disabling switch. Without admin access a live site is less vulnerable. It can be hidden but not disabled. Live should be just display of data with limited data input and change thereof. This requires another mindset for Drupal as a whole. - For us, some components, that we needed, like say Work bench, taxonomy, and several others need admin permissions for the user to enter/change data. This opens a pandora's box of risk. Alternatively we write work around code or find and install yet another set of "work around" modules to overcome the problem. This in turn introduces potential threats, risks, more maintenance, etc. To date we have several work around modules. Creating modules or rewriting is not an option for me. I do not like PHP, it's boring, cumbersome and repetitive. - Configurations are stored in the database, there is no way to dev or test without entirely separate installs which require copies of the live database updated into the dev/test areas. We can't work on updated data without potentially wrecking d/t changes and vice versa. Ideally configurations could be separate from data. Dev/test could instead be a subset of live data with just the config and display changes worked upon. We don't have the expertise to go through every table to find which is linked to which. - There is no clean, obvious way to move a small change from dev/test to live site without overwriting the database or part thereof which means that latest data may be changed or some field content no longer relates to changes. Unless yet another set of protocols is introduced with more complication. - Introducing changes as above, for us, have wrecked parts of the live system because it seems, virtually every table is referred to by every other table in some way. - When Admin, on a static IP, is locked out there is no way, apart from waiting many hours, for the ip lockout to be dropped. Unless there are 2 or 3 admins and one or those resets the lockout, not easy! - We routinely use extremely convoluted very long passwords, changed regularly. The password is the only hidden part of a log in. User names are displayed to all and sundry. For us, hiding actual user names and displaying preferred user names unrelated to login would be more secure. Barriers to hacking Drupal core are the password and the 5 tries and you're out. Hidden user name and display of preferred, but different name could add another level of security. Roger

2 1

Site Hacked
by Roger 27 Oct '12

27 Oct '12

Hi, My development website (Drupal 7.15) setup 2 weeks ago. Only View and Chaos Tools Suite Modules installed. I contacted hosting company and they said it's compromised through FTP -what I don't believe (if it's truth I'm really screwed because there is tons of other sites too :( ) I got "Security update" message but, since it's development website, I wasn't rushin' What's chances it's really FTP or something else? No other problems but "new" index page. Though, they could "planted" something? We too had very noticable attempts 2-3 weeks ago on one of our Drupal 7 sites. If anyone guesses your user name and password your'e stuffed. I had that almost happen. Caught it just in time We also had our previous Drupal 6 site hacked with some nasty code implanted into the drupal /includes system files. They got in thru the server. The isp is still in denial. Check your drupal logs/reports to see who has got in and how., regularly clean out the logs so you have fresh access detail. I suggest, delete everything on site, very difficult if you only have ftp or cpanel. Clean the site, use a new 18-25 character root password using the most convoluted range of ascii characters you can think of. Never type this when logging in as admin-- copy and paste. Never email the user or password to any one in the same email. Reinstall the full Drupal site and use similarly complex admin password. BE careful....... Drupal locks out your IP address if you enter the incorrect user name or password, I think it's 5 times but am not sure. It happened to me after 3 times. Hope this helps Roger

2 1

Varnish 2.x debugging
by Vaibhav Jain 26 Oct '12

26 Oct '12

Hello Drupal Lovers I am trying to figure out a way to debug Varnish and write some code in VCL file. I am struggling to get all attributes and properties of an object. Is there anything like print_r for varnish too. I am looking at the request object and object is "req", any way to know what all information does it contain ? Hoping to get a reply soon :) -- Regards, Vaibhav Jain

2 2

Problem getting a custom menu to display (D7)
by Ken Robinson 26 Oct '12

26 Oct '12

I have written a menu using a custom module. I can't get it to display on my test site. I used the menu example in the examples module as a guideline. My code can be seen at http://pastebin.com/VJiC5anM I've enabled the module and I know it's being executed, since I see the output of the dpm($items) call. I clear the cache every time I make a change to the code. Any help would be appreciated. Thanks in advance. Ken

3 5

My Drupal 7.15 just hacked :(
by lamp＠afan.net 26 Oct '12

26 Oct '12

3 3

ip address switch over
by Don 26 Oct '12

26 Oct '12

Hi, It doesn't look like the old ip address has been dropped yet. Can you do that now? Thanks. -Don Pickerel-

1 1

Landing page
by Waprothero＠gmail.com 25 Oct '12

25 Oct '12

I want to create a landing page, where I only gather user name and email, and show a description of my product. I am using Drupal 6. Is there a good module for this, or should I use another more general module? Thanks, Bill William Prothero http://es.earthednet.org

3 2

Using XSLT in Drupal
by Kim, Soonho (IFPRI) 23 Oct '12

23 Oct '12

Hi, I am trying to run the following code in Drupal to update local view theme. // get the iso3 code $ISO3 = $data->node_data_field_country_iso_code_field_country_iso_code_valu; // read the xslt file $themePath = path_to_theme(); $filePath = $themePath.'/xslt/GHI_en.xslt'; print $filePath; $xsl = new DOMDocument(); $xsl->load($filePath); $xslt = new XSLTProcessor(); $xslt->importStyleSheet($xsl); $xslt->setParameter( '', 'ISO3',$ISO3); $xml = new DOMDocument(); $xml->load('http:/data.ifpri.org/lod/ghi.rdf'); print (string) $xslt->transformToXML($xml); print $data->node_data_field_country_iso_code_field_country_iso_code_valu; However, I keep getting the error message saying : Fatal error: Class 'XSLTProcessor' not found in I installed php-xml and php-xslt extension. You can find my php info () here --> http://www.hyalina.com/country/SDN I also update the php.ini file to enable php-xslt and php-xml and restart the server. I guess that I did something wrong. Could you help me to find what step I was wrong? Thanks so much for your support! Best, Soonho From: support-bounces(a)drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Jeff Greenberg Sent: Tuesday, October 23, 2012 8:48 AM To: support(a)drupal.org Subject: Re: [support] Trouble with block boxes You're right. It is not. Hmmm, is there a known issue of the conversion of isam->innodb losing autonum? On Tue, Oct 23, 2012 at 8:33 AM, Richard Damon <Richard(a)damon-family.org<mailto:Richard@damon-family.org>> wrote: The fields probably aren't defined as being an "auto-increment" field in the actual database schema. Auto-increment fields automatically assign 0 values to the next number in sequence. -- Richard Damon -- [ Drupal support list | http://lists.drupal.org/ ]

1 0

Trouble with block boxes
by Jeff Greenberg 23 Oct '12

23 Oct '12

Recently converted the d6 db to innodb tables on local, dev and qa platforms. My local box seems to have an issue that the other two do not, though it may have existed prior to the conversion. I hadn't manually created blocks before then, though the site does contain blocks that predate my involvement. When I add a block, the delta in the blocks table is 0, and the boxes bid is 0. This results in, I believe, the boxes entry not being found when I edit the block, as the title, body and settings are not present. Deleting the block works correctly, and if I manually change the delta to the highest delta for 'block' + 1, and set the bid in boxes to be the same, the issue is gone. Any thoughts on why I'm ending up with the 0 value? -- --- drupal.org/user/367108 linkedin.com/in/jeffrgreenberg accidentalcoder.com / ayendesigns.com @accidentalcoder

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

support