We are creating a SCORM package (zip) and uploading to our Blackboard test instance and if one developer (will call him Bob) creates the zip and uploads then all everything works great. Myself and one other developer have packaged up the zip and uploaded it and a particular js file gets a 404 ("The specified resource was not found, or you do not have permission to access it") error when we try and run the application.
If Bob sends me his zip and I upload it to Blackboard it works fine and if I send Bob my zip and he uploads it then it fails, so I am pretty certain that is is an issue of the zip creation. I have looked at the zips and they look identical in terms of file structure.
3 questions:
Is Blackboard known to have particular problems with zip details? These do look like valid zip files.
Are there logs in Blackboard that describe the unzipping process that Blackboard uses when it installs a new SCORM package?
Is there a way to look at the deployed files/dir structure of a deployed SCORM package?
I am relatively new to Blackboard so if I missed something obvious I apologize.
I don't know any specifics about Blackboard's SCORM handling, but if your ZIP is smaller than 100MB you can test it for free at SCORM Cloud. They have a really great parser that will alert you if there is anything unusual or malfunctioning in your SCORM package. It will also let you inspect the package contents.
If it's just the one file that throws the 404 or 403, I'd check the security settings on the file. If they're too restrictive, the file may be physically present in your ZIP, but blocked from rendering by the server (hence 403) or maybe even blocked in the initial upload by the LMS (hence 404) due to insufficient privileges. I've had this happen a few times, typically on files that I downloaded from the interwebs (esp via Chrome's "Save As" file menu option) or on files I received from others.
If you're on a Mac and not a Terminal/chmod kind of guy, the easiest fix is to apply the containing folder's permissions to all enclosed items. ("Get Info" on the containing folder, then click the lock at the bottom of the Get Info window, then click the cog drop-down menu and select "Apply to enclosed items".)
We discovered that it was a path casing issue; on one of the machines the working copy of the file in question had a mix of upper and lower case in it's name and the script tag that referenced it had an all lower case path. We suspect, but can't be certain, that the server where we are running on received an update that made the http requests path case sensitive. But it may have been that way all along and one of us devs messed up out file names.
Related
My squarespace site is in developer mode. I download files, like the .region, .less, and .conf files and edit them locally. I upload these files and expect to see a change on the squarespace site.
Up until yesterday this was working, then I made a mistake in one of the LESS files and got an error about incorrectly parsed JSON in the .conf file where the LESS file was included. I got a whole ton of errors from this, and have since then fixed both the LESS file and the .conf file.
However, the issue is that my squarespace site is now not registering that any changes have been uploaded, despite the fact that my FTP files are successfully being uploaded and downloaded from the FTP server.
I have also not seen any updates to my Git on the developer mode tab since this error was registered.
My question is how to fix this, and how to start seeing edits done locally to region, etc, files again.
You can try to turn off the developer mode and then turn it on back.
I've got an OS X app that I'm distributing outside the App Store. Currently, users go to my website and download a .zip file which contains the code-signed app within. It's very important to me that users don't have to register or create accounts to use my app.
My problem is I'd like to build out referral codes into my app as a way to encourage sharing. Ideally the flow would be something like:
User A opens the app and goes to a menu option to get a unique referral link based on a UUID (to avoid collisions).
User B goes to the unique referral link and downloads the .zip, which is a specially crafted version of the app that contains the referral code. Magic referral behavior is unlocked for User B.
I'm not really concerned about users cheating the system since the code is open-source and the app is free. But since the app is code-signed I can't change it at all (and I definitely don't want to go down the rabbit hole of trying to get my Heroku server to inject a referral code and then re-sign the app), but I'm not above sneaky things like adding the referral code to the name of the app, re-zipping it on the server, and then having the app inspect its own name to extract the referral code.
That, of course, is ugly.* Are there other ways I can cleverly add the referral code to the file metadata? Or is there some completely different approach I can take to otherwise achieve my goal? No solution is too hacky!
* Ugly to the user, that is. We're way past the point of worrying about ugly architecture.
How about not zipping the app until the referral link is called. Generate an external file with the code and zip that with the app then redirect to download the newly created archive. This is relatively easy using server side scripting. You can embed the code in the file and name the file consistently every time so that when downloaded, the app looks for the file, extracts the code as necessary and deletes the extraneous file.
After some experimentation, it appears that among all of the metadata present on files, the only field that's reliably set on different systems (since my Heroku servers don't run OS X) and reliably preserved through the zipping process is the touch timestamp.
I haven't quite gotten the code to completion yet but the current plan is to have the server modify the timestamp of the .app before zipping, and then the program inspects its own timestamp to find its referral code.
If that doesn't work I'll probably go with #Jon's solution above.
I've come across a dodgy file upload on our server. It is an image and the MIME TYPE checks out, though on the server it was also uploaded with the extension .asp and .cer.
On the surface its a photo some weird chinese symbols and the letters asp, though I am sure it is hiding malicious code. I did a google search by image and it came out in a few possibly unsecure directories in some other sites.
This is out of my league to even verify. Out of interest I opened the file in notepad and it has the clear string "Google" which only makes me believe more that it is malicious.
All I need to know is
1- is it malicious?
2-did it run and what did it do?
3- how do i protect against it?
I cant give the link to the actual file on my server since Its been removed, but I can zip and mail it to anyone who wants to take a look.
If anyone has some advise on where to start I would appreciate it.
Heres a link to the same image, which came up on my google search though this one most likely has different code injected
http://www.bakjuweel.be/ShowImage.aspx?img=/upload/fotogalerijen/13/3.asp;.jpg&w=135&h=111
UPDATE
After alot more research I have found that it had a modified header to inject code. I run it through virustotal.com and my suspicious were confirmed. https://www.virustotal.com/en/file/3eac6e45d5923632089b538ca86d576c9994bd25be7940165ec997484d7c6715/analysis/
What it does or whether it executed is still unknown
OK, the file was malicious it contained encoded php, all of which im not sure of there were far too many encoded layers. It created a backdoor that fetched and executed remote code. This file was not detected by any of our antivirus software, what gave it away way was <% eval(. was the only part not encoded.A hacker took advantage of a vunerability in an old version of FCKeditor to add and execute it. I am still looking for a way to prevent it in the future.
I've been struggling with this off and on for two weeks, most of that time having been spent waiting for responses to my support issue. I have the solution, which I will post here in the hopes that it helps the next person who runs into this issue. I'm going to throw in a lot of unnecessary detail to increase the odds of the next guy finding this.
I am working on an MVC5 site, and using the ActiveReports 8 HTML5 viewer to display an IList-bound code-based section report. I have enabled PDF, Word, and Excel exports using the availableExports parameter to the GrapeCity.ActiveReports.Viewer javascript function. The viewer renders properly on the page, and makes the expected call to ActiveReports.ReportSerice.asmx, which returns the information needed to render the report, including the URL to stream the data from. The report displays in the viewer just fine. So far so good.
On my development machine, I can export to PDF, Word, and Excel. When deployed to the test server, however, the Excel export stops working, and the browser just shows a save file dialog attempting to save a file called ActiveReports.ar8?blahblahblah. Digging in with Fiddler, I determined that this is almost exactly the same as the URL returned from the call to the report service above except for a few parameters such as "Command=Export" and "ExportFormat=Xls".
Saving this "file" results in a 0-byte file called ActiveReports.xls. I can simulate this behavior for other export types by removing key dlls such as GrapeCity.ActiveReports.Export.Pdf and then asking for a PDF export, for example. It appears to me that ActiveReports (at least as of version 8.1.414.0) swallows certain server-side errors, such as missing dlls, and returns a 404 error code to the client. I think a 500 error with details about what's missing would be preferable to a generic 404.
This leads me to believe that there is something missing on the test server. Since I have "copy local" set on all the ActiveReports dlls, and I can see that they all successfully deployed to the test server, the missing piece must be something present in the GAC of my local machine, but not on the server.
Using Fiddler, I have determined that the response to the ActiveReports.ar8?blahblahblah URL has a return code of 404. The content-disposition header on the resulting 404 response has been set to "attachment; filename=ActiveReports.xls", but the Content-Type is "text/html" rather than the expected "application/vnd.ms-excel". This tells me that the export made it at least partway through processing before giving up.
What's missing on the server that's preventing Excel exports from completing?
The missing piece of the puzzle is the DocumentFormat.OpenXml.dll, a copy of which can be found in the "C:\Program Files (x86)\Common Files\ComponentOne\ActiveReports 8" folder. Ironically, it alphabetizes right next to all of the GrapeCity.ActiveReports assemblies, but without any indication of which other assemblies use it, you can easily look right past it as I did, figuring it was a dependency of something else in that folder such as the license generator.
Adding a reference to DocumentFormal.OpenXml.dll to the web project, and setting Copy Local to true ensures that the dll gets deployed along with everything else. My Excel exports work just fine now.
I apologize for the inconvenience you were facing. You are right that the 'DocumentFormat.OpenXml.dll' is also required on the server when using Excel export with ActiveReports. I've placed a request for this to be added to the documentation.
Thank you for bringing this to our notice.
Regards
I am in an interesting situation where I maintain the code for a program that is used and distributed primarily by our sister company. We are ready to distribute the program to all of the 3rd party users and since it is technically our sister companies program, we want to host it on their website. (in the interest of anonimity, I'll use 'program' everywhere instead of the actual application name, and 'www.SisterCompany.com' instead of their actual URL.)
So I get everything ready to go, setup the Publish setting to check for updates at program start, the minimum required version, and I set the Insallation Folder URL and Update Location to "http://www.SisterCompany.com/apps/program/", with the actual Publishing Folder Location as "C:\LocalProjects\Program\Publish\". Everything else is pretty standard.
After publish, I confirm that everything installs and works correctly when running directly from the publish location on my C: drive. So I put everything on our FTP server, and the guy at our sister company pulls it down and places everything in the '/apps/program/' directory on their webserver.
This is where it goes bad. When I try to install it from their site, I get the - File, Program.exe.config, has a different computed hash than specified in manifest. Error. I tested it a bit, and I even get that error trying to install from any network location on our network other than my local C: drive.
After doing the initial publish in visual studio, I have changed no files (which is the answer/reason I've found by doing some searching about this error).
What could be causing this? Is it because I set the Installation Folder URL to a location that it isn't initially published too?
Let me know if any additional info is needed.
Thanks.
After bashing my head against this all weekend, I have finally found the answer. After unsigning the project and removing the hash on the offending file (an xml file), I got the program to install, but it was giving me 'Windows Side by Side' Errors. I drilled down into the App Cache were the file was, and instead of a config .xml file, it was one of the HTML files from the website the clickonce installer was hosted on. Turns out that the web server didn't seem to like serving up an .XML (or .mdb it turns out) file.
This MSDN article ended up giving me the final solution:
I had to make sure that the 'Use ".deploy" file extension' was selected so that the web server wouldn't mangle files with extensions it didn't like.
I couldn't figure out why that one file's hash would be different. Turns out it wasn't even the same file at all.
It is possible that one of the FTP transfers is happening in text mode, rather than binary?
For me the problem was that .config transformations were done after generating manifest.
To anyone else who's still having trouble, five years later:
The first problem was configuring the MIME type, which on nginx (/etc/nginx/mime.types) should look like this:
application/x-ms-manifest application
See Click Once Server and Client Configuration.
The weirder problem to me was that I was using git to handle the push to the server, i.e.
git remote add live ssh://user#mybox/path/to/publish
git commit -am "committing...";git push live master
Works great for most things, but it was probably being registered as a "change," which prevented the app from installing locally. Once I started using scp instead:
scp -r * user#mybox/path/to/dir/
It worked without a hitch.
It is unfortunate that there is not a lot of helpful information out there about this.