The GDPR

[Goz]

OrderScript.pl, PerlScript.pl, Search.pm should not be on your server. They should only be in your Site1 folder on your PC.

When performing an upload, SellerDeck generates the scripts it needs from the scripts in the Site1 folder.

You can identify those scripts in your cgi-bin by virtue of the fact they have the script number in the filename e.g. sa000001.pm, os000001.pl etc. (although there are a couple of exceptions such as DigestSHAPurePerl.pm and JSONPP.pm but that would be dependent on which which version of SD you are using)

I would delete everything in the cgi-bin and then perform a website refresh. (Or, if you are ultra-cautious, backup the cgi-bin first)

[Mantra]

Don't FTP script files over. Let SD do that.

What version of SD are you running?

Thanks, Andrew

Version 16.0.3 RBUC

You can go into Help > Troubleshooting and then run Compare Perl Scripts - this compare your scripts against the original scripts for your version

Only 1 Perl Script listed as having been changed compared to sellerdeck originals:

MailForm.pl - change for reCAPTCHA v2 update.

I did a complete refresh (digital files and changed file boxes unticked) of the website this morning but this has made no difference to the script file date descrepancies - see screenshot attached.

I will raise a ticket with SD support.

Martin

[Mantra]

Firstly, the smtp error.....

It is saying that Spamhaus has identified your SMTP server as being infected with a botnet so it unlikely that your email will be sent or delivered.

See https://www.abuseat.org/lookup.cgi?ip=81.171.239.188

Who is the host?

Host is Claranet.

There are some more appearing today:

Program = SHOPCART, Program version = 39310 , HTTP Server = Apache , Return code = 999 , Date and Time = 2018/05/11 00:01, Internal Errors = There is no valid input parameters for the script! Check the referencing HTML code!
Program = SearchSc, Program version = 41529 , HTTP Server = Apache , Return code = 999 , Date and Time = 2018/05/11 06:17, Internal Errors = The requested file (Miscellaneous.html) is outside the scope of the script. If you believe the requested page should be served please contact the site operator.

[Goz]

Don't FTP script files over. Let SD do that.

What version of SD are you running?

You can go into Help > Troubleshooting and then run Compare Perl Scripts - this compare your scripts against the original scripts for your version

[Goz]

Firstly, the smtp error.....

It is saying that Spamhaus has identified your SMTP server as being infected with a botnet so it unlikely that your email will be sent or delivered.

See https://www.abuseat.org/lookup.cgi?ip=81.171.239.188

Who is the host?

[Mantra]

Laura, Andrew - that's interesting.
OrderScript debugging is considered in Sellerdeck desktop GDPR Recommendations and I implemented the recommendations given.
However, after your earlier post I checked our site again and found that the error messages were starting to appear again.
I compared our Site1 files with the URL cgi-bin files and found that the OrderScript.pl was dated 2009 and had not been updated with the later OrderScript.pl dated 03/11/2016 (unchanged after Notepad++ update) so I FTP'd the updated file over separately.
Since doing this the file can still be accessed with the following error listed:

Program = ORDERSCR, Program version = 43542 , HTTP Server = Apache , Return code = 999, Date and Time = 2018/05/10 13:58, Internal Errors = Error returned from SMTP server (4: https://www.spamhaus.org/query/ip/81.171.239.188)

Do not know what this means!

SD recommend that OrderScript debugging should only be enabled for a specific purpose and then disabled and the error file deleted afterwards.

I also compared other *.pl file dates and found similar discreprancies for mailscript.pl, MergeDiff.pl, nph-download.pl, PerlScript.pl, referrer.pl, SearchHighlight.pl, SearchScript.pl files and various *.pm files which is surprising as the Actinic/SD version and site has been updated/refreshed many times since 2009.

Andrew, SD - Should the most recent versions of these files also be FTP'd over?

[MrsBee]

If you block access to error.err file using htaccess does that stop you from viewing error.err from within SellerDeck?

Andrew, I just checked and yes, it does block it. I've never viewed 'error.err' from within SD though, I always access it via FTP.

[Goz]

If you block access to error.err file using htaccess does that stop you from viewing error.err from within SellerDeck?

[MrsBee]

It maybe that the server is already blocking, I think the htaccess thing was if the server wasn't. I really wanted to see if adding the htaccess entry would stop AD working (by blocking the files) but it didn't. Unless I have got it all completely wrong!

Best wishes

Jonathan

I think it must be, Jonathan. However, your code has helped me with something else (see above) so thank you

[MrsBee]

Laura, I tried this also on my site for //oldaddress.fil and this returned an access forbidden message. I tried again using //newaddress.fil and this returned a file not found on this server message.
There is no htaccess file in the catalog directory for my site.
I could not find any *.session files on my site so could not try this.
In view of the above, I can only assume that the necessary security protection is established on the server side maybe as a requirement for SSL certification.
Martin
Mantra Audio

Thanks, Martin. Ahh, you've just made me realise something - I have the same page for 404 and 403 so I was assuming they were all just coming up as 404 errors.
I just edited the 403 page slightly and I can now see what you can - /oldaddress.fil is causing a 'forbidden' 403 page, whilst any page that doesn't exist causes a 'not found' 404 page. My session files also cause a 'forbidden' 403 page.

On a related note though, I can still view my 'error.err' file and I can't see why I would want anyone viewing that. So I just altered Jonathan's code slightly to just reference '.err' files, and it has now blocked access to my 'error.err' file with a 'forbidden' 403 page. So good stuff, Jonathan! Thank you for sharing.

[Mantra]

I am waiting for this prior to making my site legal for the 25th.

Is it worth the wait?

On balance I believe Yes.
The hardest part for me was to compile a new privacy policy to address the requirements of GDPR consulting the regulations, published guidance etc. and completing an impact risk assessment for my particular business possibly in the wrong order but it came good in the end.
The control/mitigation measures required that I identified in the risk assessment for my business have been considered in the recommendations so far as SD Desktop applications are concerned together with some other aspects that I had not considered.
I have completed and uploaded the changes today as I cannot wait until 25 May to do this due to other commitments.

Martin
Mantra Audio

[graphicz]

It maybe that the server is already blocking, I think the htaccess thing was if the server wasn't. I really wanted to see if adding the htaccess entry would stop AD working (by blocking the files) but it didn't. Unless I have got it all completely wrong!

Best wishes

Jonathan

[Mantra]

Laura, I tried this also on my site for //oldaddress.fil and this returned an access forbidden message. I tried again using //newaddress.fil and this returned a file not found on this server message.
There is no htaccess file in the catalog directory for my site.
I could not find any *.session files on my site so could not try this.
In view of the above, I can only assume that the necessary security protection is established on the server side maybe as a requirement for SSL certification.
Martin
Mantra Audio

[MrsBee]

Jonathan, thank you for providing the code above. I was just about to implement it but I thought I would first check a couple of *.fil and *.session files beforehand. My 404 error page loaded straight away, which I thought was odd because I haven't yet uploaded any kind of .htaccess file to my /acatalog/ folder so in theory there should be no file-blocking going on as yet.

Would anybody know why this is happening please? I definitely typed the URLs/file names correctly (eg, https://www.mysite.com/acatalog/oldaddress.fil).

[graphicz]

The PDF suggests an htaccess file to prevent download of *.fil, *.session, *.authorise, *.mail

I have put an htaccess on a test instance of SD containing this:

<FilesMatch " *.fil, *.session, *.authorise, *.mail">
    Order Allow,Deny
    Deny from All
</FilesMatch>

and the site still seems to work. It is http://www.graphicz.solutions/gdpr/ and I put the htaccess in the acatalog directory. If you put http://www.graphicz.solutions/gdpr/a...oldaddress.fil for example in the browser address bar you now get a 404