Workbox cachefirst network request error with Giphy - service-worker

I'm using the following strategy to cache images:
workbox.routing.registerRoute(
/.*\.(?:png|jpg|jpeg|svg|webp|gif)/,
new workbox.strategies.CacheFirst({
"cacheName": "images",
plugins: [
new workbox.expiration.Plugin({
maxEntries: 60,
maxAgeSeconds: 2592000,
purgeOnQuotaError: false})]
}), 'GET');
I'm not defining any other particular strategies.
When I try it in an index.html containing a Gif hosted by Giphy:
<img src="https://media.giphy.com/media/xUA7baWfTjfHGLZc3e/giphy.gif"/>
Worbox do seeems to cache properly as long as I'm online
Using CacheFirst to respond to 'https://media.giphy.com/media/xUA7baWfTjfHGLZc3e/giphy.gif'
If I disable my wifi and try to refresh offline my page I hit the following errors:
workbox Network request for 'https://media.giphy.com/media/xUA7baWfTjfHGLZc3e/giphy.gif' threw an error. TypeError: Failed to fetch
Uncaught (in promise) no-response: The strategy could not generate a response for 'https://media.giphy.com/media/xUA7baWfTjfHGLZc3e/giphy.gif'. The underlying error is TypeError: Failed to fetch.
at CacheFirst.makeRequest (https://storage.googleapis.com/workbox-cdn/releases/4.3.1/workbox-strategies.dev.js:180:15)
GET https://media.giphy.com/media/xUA7baWfTjfHGLZc3e/giphy.gif net::ERR_FAILED
Therefore am I missing something? Should I configure something more to be able to cache Giphy gifs? Or is it actually a bug? Or something which can't be solved?
Any help appreciated, thank you in advance

My question is a duplicate of Workbox Cache First not caching properly
The answer is the one provided by Diego H Ferraz in https://stackoverflow.com/a/59040270/5404186

Related

Workbox Request method 'POST' is unsupported

I am using the code from this site: https://developers.google.com/web/tools/workbox/modules/workbox-routing
My code is as below:
workbox.routing.registerRoute(
new RegExp('http://localhost:64445.*/'),
workbox.strategies.staleWhileRevalidate({
cacheName:'Post-Run-time-cache'
}),
'POST'
);
And it gives me the error:
Uncaught (in promise) TypeError: Request method 'POST' is unsupported
I do not know what went wrong. It is from the document but it is not supported?? why. Thanks for the help.
The Cache Storage API doesn't support using a Request object whose method is not 'GET' as a cache key. Attempting to store a 'POST' request in the cache (which is happening under the hood in the staleWhileRevalidate strategy) will fail with an error similar to what you're seeing—though I think there's a more informative error logged when you're in Workbox's development mode, on localhost.
If you're looking to retry failed 'POST' requests, I'd recommend the workbox-background-sync module.

angular2 & lite server dot in url leads to 404 not found

I'm using Angular2 Beta 14 and calling a URL with a "dot" in it leads to a 404 not found error from the lite server which is 2.2.0.
This is the URL I'm calling:
http://localhost:3000/confirmuser/token/eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjYsInVzZXJOYW1lIjoiYXNkZmFzQGNlZC5saSJ9.PMzNWp8mbUKbSAiOqhOqjhZUYNejXY3pIQueBkc8_2E
The router path in app.component.ts looks like this:
{path: '/confirmuser/token/:token', name: 'ConfirmUser', component: ConfirmUserComponent}
The Chrome console shows this:
Failed to load resource: the server responded with a status of 404 (Not Found)
Ant the Lite Server:
[1] 16.04.13 15:57:13 404 GET /confirmuser/token/eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjYsInVzZXJOYW1lIjoiYXNkZmFzQGNlZC5saSJ9.PMzNWp8mbUKbSAiOqhOqjhZUYNejXY3pIQueBkc8_2E
When ever I call the url without a "dot", the page gets loaded correctly.
My aim here is, to confirm a user sign up. He receives an email with an URL he has to confirm. Using a JWT in this (and other cases) is habit I've been using.
Now I doubt this is an Angular issue, I believe this is a lite server issue.
Anyone experience with this?
Thanks
I found a suitable workaround for this issue.
Basically I'm getting rid of the path parameter ":token" and replacing it by a query parameter
In the app.component.ts the new path now looks like this:
{path: '/confirmuser', name: 'ConfirmUser', component: ConfirmUserComponent}
An the URL like this:
http://localhost:3000/confirmuser?token=eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjYsInVzZXJOYW1lIjoiYXNkZmFzQGNlZC5saSJ9.PMzNWp8mbUKbSAiOqhOqjhZUYNejXY3pIQueBkc8_2E
In the component that handles this request I can continue to call route params as I was used to. So nothing to change there:
constructor(params: RouteParams){
this.token = params.get('token')
...
This question has been answered in https://stackoverflow.com/a/36283859/1465640#
But it can be summarized with dots doesn't work in urls unless you do some work on the lite-server config.
If you are using webpack then you need to change the config to make it working.
Please make the change in webpack dev server config file
historyApiFallback: {
disableDotRule: true
},

ZF2 - Apigility not creating new api

I have Apigility running successfully on an app and have decided to use it for a new one. The problem I am stumped with is that it refuses to create a new api and appears to "hang" on the "create new api" screen.
Here is a screenshot of where it hangs: http://screencast.com/t/7CI3TN38Fm
Any advise on how to bug test this or has anyone experienced similar issues?
EDIT
When checking the console I note the following errors:
http://screencast.com/t/gIbZEWMwo
http://cloud.examplesite.dev/apigility/api/fs-permissions Failed to load resource: the server responded with a status of 403 (Forbidden)
vendor-angular.js:2 TypeError: Cannot read property 'fs_perms' of undefined
at http://cloud.examplesite.dev/zf-apigility-admin/js/app.js:1:5838
at j (http://cloud.examplesite.dev/zf-apigility-admin/js/vendor-angular.js:2:16336)
at http://cloud.examplesite.dev/zf-apigility-admin/js/vendor-angular.js:2:17013
at k.$eval (http://cloud.examplesite.dev/zf-apigility-admin/js/vendor-angular.js:2:21222)
at k.$digest (http://cloud.examplesite.dev/zf-apigility-admin/js/vendor-angular.js:2:19926)
at k.$apply (http://cloud.examplesite.dev/zf-apigility-admin/js/vendor-angular.js:2:21541)
at f (http://cloud.examplesite.dev/zf-apigility-admin/js/vendor-angular.js:2:2732)
at r (http://cloud.examplesite.dev/zf-apigility-admin/js/vendor-angular.js:2:4556)
at XMLHttpRequest.w.onreadystatechange (http://cloud.examplesite.dev/zf-apigility-admin/js/vendor-angular.js:2:5095)vendor-angular.js:2 (anonymous function)
http://cloud.examplesite.dev/apigility/api/cache-enabled Failed to load resource: the server responded with a status of 403 (Forbidden)
3http://cloud.examplesite.dev/apigility/api/module Failed to load resource: the server responded with a status of 403 (Forbidden)
http://cloud.examplesite.dev/apigility/ui#/api Failed to load resource: net::ERR_CACHE_MISS
vendor-angular.js:2 GET http://cloud.examplesite.dev/apigility/api/dashboard 403 (Forbidden)
vendor-angular.js:2 GET http://cloud.examplesite.dev/apigility/api/dashboard 403 (Forbidden)
EDIT
After further investigation it would appear ZfcRbac is the cause of the problem... to create the Api it needs to be commented out.
Not sure of the best method to work around this... will investigate and post the answer once I know.
What I did to resolve this was to create an autoload file: mydev.local.php and to include the following in it:
<?php
return [
'zfc_rbac' => [
'protection_policy' => \ZfcRbac\Guard\GuardInterface::POLICY_ALLOW
]
Problem solved. thanks!
];
This means that any route that is not in my guards is not protected... of course when going to live mode, the local override file is not included...
If you update Apigility to the dev-master this issue will go away.
In your composer.json use this
"require-dev":{
"zfcampus/zf-apigility-admin": "dev-master"
}
and please disable opcache in php.ini also.

Newbie OAuth issue: Error when trying to use the PHPoAuthLib OAuth lib

I've got an issue using this OAuth lib when connecting with twitter:
https://github.com/Lusitanian/PHPoAuthLib
I'm using the following url to connect:
http://www.myserver.com/oauth/examples/twitter.php?go=go
I'm getting the following error:
Fatal error: Uncaught exception 'OAuth\Common\Http\Exception\TokenResponseException' with message 'file_get_contents(https://api.twitter.com/oauth/request_token): failed to open stream: HTTP request failed! HTTP/1.1 401 Unauthorized ' in /webDeploy/V2/sites/wandexBB/oauth/src/OAuth/Common/Http/Client/StreamClient.php:75 Stack trace: #0 /webDeploy/V2/sites/wandexBB/oauth/src/OAuth/OAuth1/Service/AbstractService.php(52): OAuth\Common\Http\Client\StreamClient->retrieveResponse(Object(OAuth\Common\Http\Uri\Uri), Array, Array) #1 /webDeploy/V2/sites/wandexBB/oauth/examples/twitter.php(59): OAuth\OAuth1\Service\AbstractService->requestRequestToken() #2 {main} thrown in /webDeploy/V2/sites/wandexBB/oauth/src/OAuth/Common/Http/Client/StreamClient.php on line 75
It looks like the request body is empty.
I see in the code the following params are being used:
$_GET['oauth_token'],
$_GET['oauth_verifier'],
What are these params? I see in my twitter account I have various tokens available after I created my app on twitter, is it something to do with that?
I'm lost :/ This could be the wrong approach altogether.
Can anyone help with this?
Thanks in advance.
This lib seems to have a bug relating to the twitter implementation. Now using a different lib and got that going much more easily:
https://github.com/sudocode/ohmy-auth

How can I avoid this Passenger error when using Paperclip in Rails?

I frequently get this error in my Apache error_log when attempting to upload an image. It happens virtually every other request. It is so dependable that if you click "submit" twice on the image upload page, the second request works:
[ pid=53580 thr=0x7fff707b3c20 file=ext/apache2/Hooks.cpp:859 time=2010-12-15 14:13:00.309
]: Unexpected error in mod_passenger: An error occurred while receiving HTTP upload data:
The timeout specified has expired (70007)
Backtrace:
in 'void Hooks::receiveRequestBody(request_rec*, const char*, std::string&)'(Hooks.cpp:1271)
This seems to also happen to me with attachment_fu. Any idea why so many requests hang, and what I can do to avoid it?
You're likely running into the Safari Upload Bug. Its bitten me quite a few times in the past as well.
The fix, apparently, is to fire off an ajax request right before the form submits. I've been using the jQuery snippet below for a while now and it works well. There is also a non-jQuery example in the link posted above if you prefer plain javascript.
<script type="text/javascript">
$('form').live('submit', function(){
if (/AppleWebKit|MSIE/.test(navigator.userAgent)){
$.ajax({url:"/ping/close", async:false});
}
});
</script>

Resources