I have an extension hosted on github, for which I want to provide automatic updates. However, when I provide the URL to a file attached to a release, Joomla just reports the following on trying to automatically update:
Fehler beim Verbindungsaufbau zum Server: Error Unknown
Ungültige Webadresse
Translation
Error in connecting to server: Error Unknown
Invalid web address
It's the same when trying to install from the web address via the Extensions - Install page.
From the browser, I can download the file just fine however.
Anybody got an idea why that is? Is it an error on github side, or on Joomla's?
Or is it some "safety" or "security" mechanism on github side?
What can I do to avoid it? Or do those two just not play along?
Example URL: https://github.com/codeling/bfstop/releases/download/1.2.0/pkg_bfstop-1.2.0.zip
Edit:
Inserted the patch for downloadPackage method (gist.github.com/piotr-cz/8316210) mentioned by piotr_cz in the comments below the answer into my Joomla installation now.
URL passed into the method after resolving the redirect: https://s3.amazonaws.com/github-cloud/releases/6794712/f2aa5eb4-7838-11e3-837a-c6be2639e4ca.zip?response-content-disposition=attachment%3B%20filename%3Dpkg_bfstop-1.2.0.zip&AWSAccessKeyId=AKIAISTNZFOVBIJMK3TQ&Expires=1389455424&Signature=Nnyl6TnWueTqK8bPkPXUidM8UzQ%3D
URL after the newly inserted lines: https://s3.amazonaws.com/github-cloud/releases/6794712/f2aa5eb4-7838-11e3-837a-c6be2639e4ca.zip?response-content-disposition=attachment; filename=pkg_bfstop-1.2.0.zip&AWSAccessKeyId=AKIAISTNZFOVBIJMK3TQ&Expires=1389455424&Signature=Nnyl6TnWueTqK8bPkPXUidM8UzQ=
The response is still a 505 error:
response: JHttpResponse Object
(
[code] => 505
[headers] => Array
(
[Date] => Sat, 11 Jan 2014 15:49:24 GMT
[Connection] => close
[Server] => AmazonS3
)
[body] =>
)
So I suppose the encoding doesn't matter. The error 505 would indeed indicate http version problems? Why would Joomla and Amazon disagree on HTTP versions? Definitely not an HTTP expert here but version 1.1 should be the unchanged standard version since more than 10 years now?
Conclusions:
Automatically generated downloads by GitHub's Tags and Releases are compatible with Joomla Installer at this moment (Jan 2014) as long as the repository name matches extension name (element). Joomla Installer is able to work with an extension which:
Have files and folders located directly:
mod_mymodule.zip:
/mod_mymodule.xml
/mod_mymodule.php
Or have files and folders located in a folder of the same name as the archive (see JInstallerHelper::unpack):
mod_mymodule.zip:
/mod_mymodule
/mod_mymodule/mod_mymodule.xml
/mod_mymodule/mod_mymodule.php
This is how GitHub Tags and Releases are built now. Automatically generated downloads of repository mod_mymodule results in mod_mymodule-[tag/branch].zip archive with mod_mymodule-[tag/branch] subfolder. Say when we tag extension 1.0.0-beta:
mod_mymodule-1.0.0-beta.zip:
/mod_mymodule-1.0.0-beta
/mod_mymodule-1.0.0-beta/mod_mymodule.xml
/mod_mymodule-1.0.0-beta/mod_mymodule.php
Note: There were some changes in how archive is built (see Automatic Extension Update: Unknown Archive type)
Manually attached Binaries added to a GitHub Release are hosted in the Amazon Web Services. Request to download these by JInstallerHelper::downloadPackage results in an response 505 HTTP Version Not Supported and we didn't find a working solution for this problem yet.
In the end one may use GitHub as an Joomla Extensions Update server (it's pretty convenient), as long as you use automatically generated downloads.
GitHub provides Version Control service, not an Update server so the way how downloadable archive is built may change again in future.
Until we find out a way how to download Attached Binaries (where one have full control over archive's name and structure) using Joomla Installer, GitHub should not be perceived as a reliable tool for Joomla extension updates. I believe there's a way to patch the JInstaller package to be compatible with the AWS (download works fine using command-line curl).
Thanks for ccpl and RandolphCarter on getting information for this answer.
It would appear that URL is redirected to an S3 location:
https://s3.amazonaws.com/github-cloud/releases/6794712/6c173582-77ef-11e3-9aec-c8994b691269.zip?response-content-disposition=attachment%3B%20filename%3Dpkg_bfstop-1.2.0.zip&AWSAccessKeyId=AKIAISTNZFOVBIJMK3TQ&Expires=1389163120&Signature=c4RdRTAUZ5%2FDHlpg0vR2ivK6lQQ%3D`
As a guess I would say this breaks the install from web.
Updated
Doing a bit further tracking, I can see the downloadPackage() method does catch the 302 Found and try to get the file from the new URL. At this point it does a new curl request with some basic options:
$options = array("10036" => "GET",
"10065" => "/Users/cppl/Sites/jdev/libraries/joomla/http/transport/cacert.pem",
"10002" => "https://s3.amazonaws.com/github-cloud/releases/6794712/f2aa5eb4-7838-11e3-837a-c6be2639e4ca.zip?response-content-disposition=attachment; filename=pkg_bfstop-1.2.0.zip&AWSAccessKeyId=AKIAISTNZFOVBIJMK3TQ&Expires=1389170600&Signature=BVlqH0hVhYGjbeKn6w/9nDn+kDg=",
"42" => "1",
"19913" => "1")
Unfortunately the S3 service is returning a 505
HTTP/1.1 505 HTTP Version Not Supported
Date: Wed, 08 Jan 2014 08:47:59 GMT
Connection: close
Server: AmazonS3
Hacking around in \JHttpTransportCurl\request I tried
forcing CURL_HTTP_VERSION_1_1
disabling SSL verification CURLOPT_SSL_VERIFYPEER (useful in other S3 situations)
updating the cacert.pem to the current one
all together
Nothing worked.
So far it all appears to be on AWS side, I'm not aware of all the S3 access controls possibly there's something in the GitHub setup of their S3 buckets.
I haven't got the direct approach to work (to use the release assets for automatic update), therefore I am now implementing the workaround solution by putting the files into the git repository.
Not an ideal solution, I know, but at least that works.
Related
Connected the podio file upload to attach images to item. Started getting the "Connection to Podio API failed: [92]" error. Before everything worked fine. Is it a problem on my side or on Podio's side?
Podio does not define CURLOPT_HTTP_VERSION variable in it's curl requests and therefore leaving the decision to curl client to decide.
in your case I guess cURL chooses HTTP2 version for unknown reasons ( might be due to SSL implementation ) and according to my experience with Podio, PodioFile::upload breaks when HTTP2 is used.
To solve the issue you would need to force Podio to use HTTP1.1 , This should fix your issue :
inside lib/Podio.php look for curl_setopt(self::$ch,CURLOPT_RETURNTRANSFER, true);
just beneath it add curl_setopt(self::$ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_1);
Tip: do consider upgrading to the latest version of the package podio-community/podio-php before modifying the code and Good luck.
In dynamics CRM 2016 I have a custom button that opens up a HTML WebResource and runs some JavaScript.
It works perfectly in our development environment.
However, in our pre-production it gives the message:
500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.
F12 Debugging only provides the same message, and i cannot access the specific resources (the code) because it is a managed solution in preproduction.
Google only return very general "500 error fixes", or similar questions that have not been answered, that are very old.
Any suggestions how to go about this?
(And yes I have checked that it is actually pointing at the correct files).
It turns out that in the RibbonWorkbench in the Url command the path called, begins with /Udv/WebResources/myPage.htm, which is a hardcoded part of the development path.
The answer was to change the parameter to $webresource:myPage.htm
My goal: I'd like to use an image from commons.mediawiki.org within a MediaWiki installation.
First I was trying to debug my InstantCommons configuration: Referring to files on commons.mediawiki.org failed for some reason. After activating various debugging options I learned that though general image download succeeded some kind of thumbnail followup request issued by the MediaWiki installation failed, which resulted into an overall error from the ForeignAPIRepo-Module.
As I can not deal with this error right now I thought I'd try something else as some kind of fallback: Download the MediaWiki image by specifiying the image URL in the upload image web page. The idea is to let MediaWiki download the image and include this image as regular wiki content. This way I would require to add license details manually and add a few comments, but this would be better than having no image.
But trying this I strangely get an error: It says "Fehler beim Senden der Anfrage" which means "Error while sending the request". But the internal request seems succeed in the logs. Here is what MediaWiki was logging:
[fileupload] Temporary file created "/tmp/URLdafce5345aa3-1"
[fileupload] Starting download from "https://upload.wikimedia.org/wikipedia/commons/c/c7/Broccoli%2C_Champignons%2C_Karotten_%2810581663524%29.jpg" <followRedirects>
[fileupload] <Error, collected 1 error(s) on the way, integer value set>
+------+---------------------------+------------------------------------------+
| 1 | http-request-error | |
+------+---------------------------+------------------------------------------+
[fileupload] Download by URL completed with HTTP status 200
Comment: All other log messages do not indicate anything that looks like an error or is related to the task of downloading the image, so I skipped them here.
The URL is correct, the image can be downloaded from the URL, MediaWiki receives a response code of 200, but instead of processing the response it indicates an error. Why? For http and https URLs I get the same result in the log.
Has anybody encountered this problem before in MediaWiki installations? Does anyone have any idea what the reason for this behaviour could be?
Comment: The wiki is of version 1.25.2 and a standard installation including SWM on an up to date standard Ubuntu Linux OS. Nothing exotic, nothing modified in any way.
Comment: Yes, I could upgrade to the latest version but, I'm not sure if this really solves the problem: I know that this featured did work in some other MediaWiki installations I have set up some time ago. Does anyone have a clue why this feature could fail here? Has anyone encountered something like this before?
Edit: I experimented with downloading from another MediaWiki instance of exactly the same version - 1.25.2 - in my local network. This did not succeed as well. But I get a different error message (translated): "The file .... could not be stored at ...". The "funny part": Though the error message indicated otherwise the file has been downloaded successfully and stored as expected. It has the correct user rights as one would expect, but log messages indicate that there are bugs in MediaWiki regarding this part: ("PHP Notice: Undefined property: UploadFromUrl::$nbytes") Maybe the uploading implementation is buggy somehow and the problems I am running into are typical?
There are multiple bugs with HTTPS support in MediaWiki, php-curl etc. See https://www.mediawiki.org/wiki/InstantCommons#HTTPS for debugging information, there is no magic bullet.
I have developed a Web Pages 2 website for my company using WebMatrix 2 that includes a simple SQL Compact Edition (.sdf file) database. Sounds simple. Runs perfectly on my local development box.
However, upon FTP to my Web host, it's a no-go. The first error I received was this:
Server Error in '/' Application.
Unable to find the requested .Net Framework Data Provider. It may not be installed.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.ArgumentException: Unable to find the requested .Net Framework Data Provider. It may not be installed.
Source Error:
Line 1: #{
Line 2: WebSecurity.InitializeDatabaseConnection("Omniflow", "UserProfile", "UserId", "Email", true);
Line 3: }
I have searched and searched and searched the Internet, trying to find out what the source of this problem is and how to fix it. I haven't found the answer yet. I gather than apparently some needed assemblies/dlls are not being uploaded with the application. I have tried both FTP and the Web Deploy method with no fix.
Is this the root of the problem? And why does WebMatrix not upload all its dependencies? If it cannot, why is there nothing in the online literature from Microsoft--and it should come from Microsoft--or anyone else describing this issue?
Are you using one of the hosting sites listed on the Microsoft WebMatrix page: http://www.microsoft.com/web/webmatrix/ ? I know that when I deployed my WebMatrix site to a generic IIS server, it took some extra DLL's in the bin directory, and a couple of settings to be fine tuned before it worked.
While publishing check whether your have selected Database file( .sdf file ) or not.If not then select it and publish.
Hope it will work for you.
Ensure that you have all the SqlCE DLLs required for accessing the SqlCE database.
They should be present in the bin\, bin\x86\ and bin\AMD64\ folders.
You can try creating a new site using Site from Template -> Empty Site (ASP.NET) and checking the bin folder to see which all dlls are present.
If you don't already have them in your site, add them. That should solve your problem.
I have a site running in Hostgator shared-hosting account with Google Checkout (GC) working since v1.2 - when the site first gone live, the GC works out-of-the-box.
Recently I moved the site to a VPS server and GC stopped working with this error:
Google Checkout: Invalid response from Google Checkout server
I thought it couldn’t be an issue with Magento’s Google Checkout integration but the new VPS server or maybe SSL cert that require further testing, so I moved the site back to the shared server (the GC starts working again!), and then setup a test site with a valid SSL cert, a working GC account.
3 weeks had passed still GC wouldn’t work in the VPS server; I have tried/searched/tested all possibilities along with the help from Hostgator’s support, and we have exhausted all options to a point that we believe it has nothing to do with SSL cert setup nor the server configuration.
From the above error and the log from "var/log/payment_googlecheckout" I reckon it couldn’t redirect to checkout.google.com/schema/2
<order-processing-support>
<request-initial-auth-details>true</request-initial-auth-details>
</order-processing-support>
</checkout-shopping-cart>
[dir] => out
It seems a number of people had experienced the same error before but no one seems to be able to find the cause, and I am starting to think it’s a bug lies on Magento’s Google Checkout module.
If you had this issue before and had it solved, please share. Thanks!
This person seems to have had a similar problem and it was due to an issue with their cURL installation. Have you compared versions from your shared hosting with your VPS? I'd compare: PHP versions, PHP extension versions, php.ini settings, and versions of cURL itself.
If none of that bring about any results, open up app/code/core/Mage/GoogleCheckout/Model/Api/Xml/Abstract.php and modify the _call() method like this:
// app/code/core/Mage/GoogleCheckout/Model/Api/Xml/Abstract.php
public function _call($xml)
{
// ... snip ...
$result = #simplexml_load_string($response);
if (!$result) {
// Add this...
Mage::log(var_export($response, true), null, 'google_checkout_debug.log', true);
// ... end
$result = simplexml_load_string('<error><error-message>Invalid response from Google Checkout server</error-message></error>');
}
With this, you will have the exact response from Google logged to var/log/google_checkout_debug.log. Use this to debug what might be going wrong (perhaps there is another error message embedded in the response).
Just remember to remove the code when you're done!