Closed tyssen closed 13 years ago
I think this is possible if you edit your .htaccess file. I am no .htaccess expert but I would try something like this on the other server:
order deny, allow
deny from all
allow from http://mysite.com/
So in this example your EE install is on http://mysite.com/
and you are placing this modified .htaccess file on your other server.
Then your file path in VWM Secure Files would be something like:
http://othersite.com/secure/awesome.txt
I'll mess around with this later to see if it actually works.
Ahh... Well I'm currently using file_exists to see if the file exists. That seems to only work on files on the same server. I'll try to add this feature in the next version.
I just made some quick changes to mod.vwm_secure_files.php. Tell me if that works for ya.
Thanks, I've updated to the new version but now get 'You are not allowed to download this file.' I want the file to be downloadable by anyone and have tried it with all allowed groups selected and no allowed groups selected.
Gotta love the GitHub keyboard shortcuts... I think I fixed that issue with my latest update to vwm_secure_files_m.php
. Tell me if that works for you.
Not getting the error now but instead the browser just hangs - white page and loading icon spinning endlessly.
Humm... I'll look into this tomorrow. What are your group/member settings for the file?
Actually just tried with a text file and it worked OK. The file I was linking to before was a quite large MP3 (200+Mb).
I think that may be one problem with this module. It loads the file into memory and then spits it out to the user. As far as I know that is the only way of doing it. I'll have to look into this however. Currently, I think the maximum file size would be somewhere around the max amount of memory you have allotted for PHP (minus the memory used by EE).
I am now using the readfile function. It should work better with large files. It is still probably best if these files are on your own server. Right now it can only get the file size (used for the download progress bar) for local files. I'll work on getting the file size for remote files later.
Excellent, that's fixed it! Thanks for following it up.
Sweet, glad it is working
I've now moved from local dev to production server and am getting the same 'You are not allowed to download this file.' error I was getting earlier.
Is this the same version of EE on the production server? What version of PHP is on the production server?
Actually, I've upgraded both local and production to EE 2.2 since I had a problem with it originally. PHP is at v 5.2.14.
OK, I have yet to try out EE 2.2. I'll try that later tonight.
I just tried with EE 2.2 and it worked for me. There may be some shenanigans (ooo yeah...) going on with how the user IDs are being stored. I would recommend busting open phpMyAdmin and looking at the exp_vwm_secure_files_files
table. Find the data for the file(s) you are having problems with. Take a look at the allowed_groups
, allowed_members
, denied_groups
, and denied_members
columns. These should be comma separated user IDs. So if you are allowing members 2, 3, and 4 to access your file, then the allowed_members
column will be 2,3,4
.
It could be that these values somehow got messed up... I am not sure how, but it is worth checking out.
If you want to see all your members and their corresponding IDs check out the exp_members
table.
If your still having problems I should be down for some remote assistance later in the week.
Just took a look and the allowed_members column has the correct member group IDs but still get the disallowed error message.
Maybe a MySQL dump of some of the problemed rows can help me debeg this.
Do you mean just of the vwm_secure_files_files table or do you need other
tables too?
On Fri, 01 Jul 2011 11:56:46 +1000, vmichnowicz
reply@reply.github.com
wrote:
Maybe a MySQL dump of some of the problemed rows can help me debeg this.
If you export the exp_vwm_secure_files_files
table you get something like this:
INSERT INTO `exp_vwm_secure_files_files` (`id`, `hash`, `file_path`, `allowed_groups`, `allowed_members`, `denied_groups`, `denied_members`, `download_limit`, `downloads`, `created`, `updated`) VALUES
(1, 'dbf8b576ffa9905795034751ca72cec8', 'secure/test.txt', '1,3,4', '1', NULL, NULL, 0, 0, 1309487688, NULL),
(2, 'a061261f3266dd37deaf359e25a645b2', 'asdf', '2', NULL, '2', NULL, 0, 0, 1309487750, NULL);
All I need is something this:
(1, 'dbf8b576ffa9905795034751ca72cec8', 'secure/test.txt', '1,3,4', '1', NULL, NULL, 0, 0, 1309487688, NULL)
There's only two rows so far:
11, 'bb0b321624d460eb5ed83fbf9145cd36', 'file.mp3', '1,2,3,4,5', '1',
NULL, NULL, 0, 0, 1309168565, 1309318820
12, 'bc9f3a5d77a87f89b7599069679ec347', 'file2.gif', '1,2,3,4,5', NULL,
NULL, NULL, 0, 0, 1309318859, 1309318893
On Fri, 01 Jul 2011 12:39:07 +1000, vmichnowicz
reply@reply.github.com
wrote:
If you export the
exp_vwm_secure_files_files
table you get something
like this:INSERT INTO `exp_vwm_secure_files_files` (`id`, `hash`, `file_path`, `allowed_groups`, `allowed_members`, `denied_groups`, `denied_members`, `download_limit`, `downloads`, `created`, `updated`) VALUES (1, 'dbf8b576ffa9905795034751ca72cec8', 'secure/test.txt', '1,3,4', '1', NULL, NULL, 0, 0, 1309487688, NULL), (2, 'a061261f3266dd37deaf359e25a645b2', 'asdf', '2', NULL, '2', NULL, 0, 0, 1309487750, NULL);
All I need is something this:
(1, 'dbf8b576ffa9905795034751ca72cec8', 'secure/test.txt', '1,3,4', '1', NULL, NULL, 0, 0, 1309487688, NULL)
I don't see anything out of the ordinary. I plugged in that data and it worked for me. I'll prepare a debug file sometime soon (maybe this weekend) that can hopefully help get to the bottom of this.
Try replacing mod.vwm_secure_files.php
with this version. This may help me figure out what the problem is.
Not getting an error with that one but instead getting returned to a page on my site that sits outside of EE. I've actually got EE and Wordpress running side by side with WP running off index-wp.php and ?ACT=25031984&ID=bc9f3a5d77a87f89b7599069679ec347 is taking me to a page that would be served up by WP.
That is kinda weird. That version of mod.vwm_serure_files.php
should be exactly the same as the the other version. The only difference should be how the errors are reported.
That URL does not seem correct... Are you sure that your action ID (ACT
) is 25031984
?
Do you have any other EE modules that have any action IDs working properly on your EE install?
I just tried uninstalling and reinstalling the module and the ACT ID is
now 25031985 instead of 25031984 but still getting the same result.
On Tue, 05 Jul 2011 12:46:12 +1000, vmichnowicz
reply@reply.github.com
wrote:
That is kinda weird. That version of
mod.vwm_serure_files.php
should
be exactly the same as the the other version. The only difference should
be how the errors are reported.That URL does not seem correct... Are you sure that your action ID
(ACT
) is25031984
?Do you have any other EE modules that have any action IDs working
properly on your EE install?
Hummm... I really don't know what to say. I have no experience running Wordpress and EE side-by-side. I guess you could check out your .htaccess and see what kinda stuff is going on in there?
I don't think it's an .htaccess issue because I just tried disabling it
and got the same result. And to make things more confusing, the links work
OK on my local install but not on the live server. And the only thing that
should be different between the two is a couple of lines in the .htaccess
file. :?
On Wed, 06 Jul 2011 11:30:32 +1000, vmichnowicz
reply@reply.github.com
wrote:
Hummm... I really don't know what to say. I have no experience running
Wordpress and EE side-by-side. I guess you could check out your
.htaccess and see what kinda stuff is going on in there?
It could be good to double check the EE config settings. When moving a site from your development system onto a live server there are quite a few configuration options that you have to change. Also, .htaccess rules are recursive. So if you have an .htaccess file in a higher directory, it will effect all directories and files inside it. You could also check your server logs to see if anything weird is going on.
I use a config bootstrap so my config settings between local and remote
are the same. The only config settings that might need to be different are
upload directories and I use relative paths for those and they work fine.
Which config settings did you think might cause a problem?
For .htaccess, I've only got the one, in the root directory of the main
site.
I've checked out the error logs and am not seeing anything.
On Thu, 07 Jul 2011 11:48:40 +1000, vmichnowicz
reply@reply.github.com
wrote:
It could be good to double check the EE config settings. When moving a
site from your development system onto a live server there are quite a
few configuration options that you have to change. Also, .htaccess rules
are recursive. So if you have an .htaccess file in a higher directory,
it will effect all directories and files inside it. You could also check
your server logs to see if anything weird is going on.
So the problem is that when you try to download the file it routes you to a page that serves up your Wordpress? How are you running WP and EE side by side exactly? I have never tried that so I know nothing about it.
Sorry, I'm an idiot. Have sorted out that issue and am now getting this
error message: "The action you have requested is invalid."
On Fri, 08 Jul 2011 12:18:11 +1000, vmichnowicz
reply@reply.github.com
wrote:
So the problem is that when you try to download the file it routes you
to a page that serves up your Wordpress? How are you running WP and EE
side by side exactly? I have never tried that so I know nothing about it.
Haha, I have those moments a lot...
I think this may be related to your weird action ID. There is no reason your action ID should be that high. Unless you have millions of addons installed.
Take a look at your exp_actions
table. Find all the entries with a class
of Vwm_secure_files
. Are all your other action IDs that long? I don't know why it would be a problem, but if only that action ID is weird you could change it to another integer and reset the auto increment to something reasonable.
Had a look at exp_actions and there's two other modules with really high
action_ids - Mountee and Beanstalk Ping. Everything else is one or two
digits. You can see from the list below though that it's not like it's
suddenly started happening to all new modules after a certain point.
25031985 Vwm_secure_files 37 Safecracker 38 Safecracker 39 Freeform 25031982 Mountee 40 Disqus 41 Tagger 25031983 Beanstalk_ping
On Fri, 08 Jul 2011 12:55:01 +1000, vmichnowicz
reply@reply.github.com
wrote:
Haha, I have those moments a lot...
I think this may be related to your weird action ID. There is no reason
your action ID should be that high. Unless you have millions of addons
installed.Take a look at your
exp_actions
table. Find all the entries with a
class
ofVwm_secure_files
. Are all your other action IDs that long?
I don't know why it would be a problem, but if only that action ID is
weird you could change it to another integer and reset the auto
increment to something reasonable.
Using Opera's revolutionary email client: http://www.opera.com/mail/
I would try making the ID of Vwm_secure_files
42
- for funsies. Maybe that will do something...
OK, finally got to the bottom of it: allow_url_fopen was set to off on the remote server. All fixed now. :) Thanks for your patience in helping me out.
Ahh, good call. I didn't think of that. I just added a note to that in the readme file.
It seems that the module doesn't work with files that are located on other servers and linked to via http. It'd be useful if it did.