Upload NukeSentinel 2.4.2pl9 problems with EDM v.1.7

New Member Joined: Oct 22, 2004 Posts: 6

Hi Raven, excuse for my bad english....i have a problem after the upgrade NukeSentinel 2.4.2pl9 with Enhanced Downloads Module v.1.7. If i sumbit a new download, when i click the submit botton i'm redirect to a error 406 page...Not acceptable error from the server. The serveur has received one demanded not permissible or contrary to the policy. This error can be caused from one situated attempt of hacking of or from one demanded HTTP containing of the errors. Why this? I must configure anything?
Tnx for response

Involved Joined: Jul 15, 2004 Posts: 252 Location: OKC, OK

what is the name of the file? A lot of upload errors are caused by special characters like () "" '' , !*% and other things like that, if it has any characters other a-z and 1-9 in it you may try to rename the file.

Otherwise I am sure one of the admins here will come by and have some other ideas

Posted: Thu Jul 06, 2006 2:12 pm

Is the link to the download to a file which is on the same server as your site?

Posted: Thu Jul 06, 2006 5:11 pm

I believe this is the same problem with just about the same scenario:

http://www.ravenphpscripts.com/postt10227.html

no real workaround as raven states but nsn downloads do not do this in the same manner.

Posted: Thu Jul 06, 2006 5:57 pm

Yes, thats why I asked if the url was to another site.
Sentinel see's 'http' appearing twice as a cross site scripting attack which is one of the most common forms of attack and certainly has been the case recently on a large number of sites, in particular the recent spate of phpbb_root_path attacks.

For the record, the reason why it isn't a problem for me with NSN GR Downloads is because it is tweaked so that all my links use the server root path to link to the file instead of a url and I only link to d/l's that are on my server.

Posted: Thu Jul 06, 2006 7:13 pm

I use nsn downloads and under no circumstances do I ever see mysite.com/something?=http.....

Thus the reason I offered.

registered · Posted: Thu Jul 06, 2006 10:51 pm

darklord, have you tried the scenario of a "normal user" submitting a new download and the download is an external link. Then, the admin reviews the submitted download and tries to "test the link" function? I wonder if you would see the http:// then?

Posted: Thu Jul 06, 2006 11:01 pm

I just tried it and nope.

Also if I'm not mistakin, it uses a variable to call on the download through the database, no GET in it at all, and perhaps I'm mistakin but doesnt it need the GET function to call on a variable defined in the url? Just a thought.

Posted: Thu Jul 06, 2006 11:04 pm

Ok, good to know. Was wondering if that scenario was also present in NSN Downloads. Thanks for checking.

:clap:

Posted: Fri Jul 07, 2006 2:44 am

montego, yes of course with the scenario of a normal user when i submitted the download and tries to test the link the response is "url is invalid" but in the ftp server there is the file and the andress is right!

Posted: Fri Jul 07, 2006 2:47 am

for my problem write up i use two server for my download but the problem there isn't with another version of NSN for expample my site is in php platinum 7.6b4 and the sentinel version base is 2.4.2pl3 and i don't have these problem, after the upgrade i have this and when i submitted the download i'm redirect to the page error 406.... www.domain.com/admin.php

Posted: Fri Jul 07, 2006 3:24 am

i'm resolve this problem When i access in my admin download panel and configure the name of file, size, version, etc. in homepage, if i put in the url http://www.domain.com there is the error 406 if i don't put http:// but only www.domain.com i can submit the download

Posted: Fri Jul 07, 2006 4:58 am

Excellent news!
Did you check that when you are only logged in as a normal user, clicking the link in the downloads section does not produce any errors?

Posted: Mon Jul 10, 2006 12:18 pm

Guardian2003, yes of course it's the same for the normal user

Posted: Mon Jul 10, 2006 12:26 pm

Excelent news then. I just wanted to check there was not something else that might happen if you were not logged in as an admin. It's great you found a work around.