I'm working on a VueJS app, and I want to use the Yahoo! Shopping API (documentation: https://developer.yahoo.co.jp/webapi/shopping/shopping/v1/itemsearch.html) to fetch products using their barcode. However, I keep getting a CORS error and I'm not sure why, or what I can do to make it work. My code is as follows:
data() {
return {
appId: 'dj00aiZpPUQ4RTBUUTVSNUs3TyZzPWNvbnN1bWVyc2VjcmV0Jng9NTI-',
apiUrl: 'https://shopping.yahooapis.jp/ShoppingWebService/V1/json/itemSearch'
}
}
...
axios.get(this.apiUrl, {
params: {
appid: this.appId,
jan: 4589707054951
}
})
.then((response) => {
console.log(response);
})
.catch((error) => {
alert(error)
})
The specific error I get is this:
Access to XMLHttpRequest at
'https://shopping.yahooapis.jp/ShoppingWebService/V1/json/itemSearch?appid=dj00aiZpPUQ4RTBUUTVSNUs3TyZzPWNvbnN1bWVyc2VjcmV0Jng9NTI-&jan=4589707054951'
from origin 'https://0.0.0.0:8080' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource.
What can I do to make this work? So far the only way it works is using the CORS Chrome extension, but that's naturally just for testing.
Thanks a lot.
The server/api owner needs to send this in his response header:
Or if you have a server settings panel or something, make sure to add the domain from where you are making the request.
Access-Control-Allow-Origin: 'your-domain-here'.
Please read more at: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
I got the same error. I solved it in the following manner.
This error occurs because we are tryign to access the data hosted on a different server. CORS issue is a browser issue where a certain browser does allow you to access the contents hosted on a different or a virtual server. If you observe the app that you are running on is on the local-host (https://0.0.0.0:8080) and trying to access the data hosted on https://shopping.yahooapis.jp/ShoppingWebService/V1/json/itemSearch. You can solve this problem simply by adding in a few lines of code in your vue application.
Step 1:
Create a new file called vue.config.js in your root directory of the vue application, that is beside your package.json file. Add the following code in your vue.config.js file:
module.exports = {
devServer:{
proxy: "https://shopping.yahooapis.jp"
}
}
Note: https://shopping.yahooapis.jp would be your base url.
Step 2:
Now, go back to your code in data(). Replace the domain name/base url of the apiUrl with https://0.0.0.0:8080. that is now your apiUrl would be https://0.0.0.0:8080/ShoppingWebService/V1/json/itemSearch.
data() {
return {
appId: 'dj00aiZpPUQ4RTBUUTVSNUs3TyZzPWNvbnN1bWVyc2VjcmV0Jng9NTI-',
apiUrl: 'https://0.0.0.0:8080/ShoppingWebService/V1/json/itemSearch'
}
}
Step 3:
Restart your application. Eg, npm run serve.
I found another solution which worked without creating a proxy server or a mock server. You can disable the security settings for accessing cross origin apis on your web browser.
You can disable the CHROME security settings for accessing apis out of the origin by typing the below command on the terminal:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir="/tmp/chrome_dev_session" --disable-web-security
After running the above command on your terminal, a new chrome window with security settings disabled will open up. Now, run your program (npm run serve / npm run dev) again and this time you will not get any CORS error and would be able to GET request using axios.
Hope this helps!
Related
I made an Svelte Kit its working in my local with no problem but when i build it like this:
import adapter from '#sveltejs/adapter-static';
export default {
kit: {
adapter: adapter({
fallback: 'index.html',
})
}
};
And gives me 3 folders and they are: client, prerendered, server.
I'm uploading this 3 folders in my hosting and move the folder files into root folder. Everythings works with no problem BUT i have an api that sends mail. It's gives me 404? Send mail is working in localhost but not working in hosting. I can't fixed it. In manifest.json:
{
type: 'endpoint',
id: "api/sendMail",
pattern: /^\/api\/sendMail\/?$/,
names: [],
types: [],
load: () => import('./entries/endpoints/api/sendMail/_server.js')
},
The path is correct by the way.
The folders in hosting:
Photo
What can i do?
By specifying a fallback page, this means you're turning SPA mode on, so you can't use server endpoints.
From the adapter-static readme:
You can use adapter-static to create a single-page app or SPA by
specifying a fallback page.
The reason this is working local in dev:
During development, SvelteKit will still attempt to server-side render
your routes. This means accessing things that are only available in
the browser (such as the window object) will result in errors, even
though this would be valid in the output app. To align the behavior of
SvelteKit's dev mode with your SPA, you can add export const ssr =
false to your root +layout.
I'm working on e2e test with cypress on my application.
In my case the login are manage by a external service.
When I want to enter in my application's home page (https://myApplication/home), the system redirects me in different superdomains to login.
At first cypress seems to be able to change the superdomain, but once arrived in external service page for the authentication, the system go in login error (as if we have already logged in, but incorrect).
This type of behavior does not happen outside the cypress .
Are there alternative solutions to manage external access in a cypress test or is it possible to manage it directly from cypress?
I added in my cypress.json the chromeWebSecurity:false and when I call the link for login, I added the failOnStatusCode: false,
but it still doesn't work.
Assuming this is caused by SameSite cookie blocking , then I've just been fighting the same issue. I resolved it by intercepting all requests, checking if they had a set-cookie header(s) and rewriting the SameSite attribute. There's probably a neater way to do it, as this does clutter up the cypress dashboard a little.
Sadly Zachary Costa's answer no longer works as Chrome 94 removed the SameSiteByDefaultCookies flag.
You can add this as a command for easy reuse:
In your commands file:
declare namespace Cypress {
interface Chainable<Subject> {
disableSameSiteCookieRestrictions(): void;
}
}
Cypress.Commands.add('disableSameSiteCookieRestrictions', () => {
cy.intercept('*', (req) => {
req.on('response', (res) => {
if (!res.headers['set-cookie']) {
return;
}
const disableSameSite = (headerContent: string): string => {
return headerContent.replace(/samesite=(lax|strict)/ig, 'samesite=none');
}
if (Array.isArray(res.headers['set-cookie'])) {
res.headers['set-cookie'] = res.headers['set-cookie'].map(disableSameSite);
} else {
res.headers['set-cookie'] = disableSameSite(res.headers['set-cookie']);
}
})
});
});
Usage:
it('should login using third party idp', () => {
cy.disableSameSiteCookieRestrictions();
//add test body here
});
or alteratively, run it before each test:
beforeEach(() => cy.disableSameSiteCookieRestrictions());
We were encountering a similar issue, where Cypress was redirecting us to the default "You are not logged in" page after getting through the login process. I'm not certain if that's EXACTLY the issue you were experiencing, but just in case, here's our solution. In our case, the issue was caused by Chrome's "Same Site Cookies" feature interacting poorly with Cypress, so we needed to disable it. In your plugins/index.js file, you would add the following code:
module.exports = (on, config) => {
on('before:browser:launch', (browser, launchOptions) => {
if (browser.name === 'chrome') {
launchOptions.args.push('--disable-features=SameSiteByDefaultCookies');
}
return launchOptions;
});
};
Note that if you already have launchOptions being set, you can just add this code onto it so it doesn't clash at all.
Hopefully, this works for you as well!
In the current version of cypress you can't go to another domain in the same test. This is due to the fact that cypress injects its test into the browser (they are working on this issue).
So one solution today is that you need to utilize cy.request to perform the login programmatically and inject the auth secret (jwt, cookie, localstorage, token or what you have) into the browser context yourself (for cookie this would be cy.setcookie).
Always make sure to checkout the plugins if there is already an abstraction for your login. Often this is openId or ntlm.
I'm hoping someone can tell me if I'm barking up the wrong tree. I have built a basic web app using Vue CLI and included the PWA support. Everything seems to work fine, I get the install prompt etc.
What I want to do, is cache various pages (routes) that user hasn't visited before, but so that they can when offline.
The reason here is that I'm planning to build an app for an airline and part of that app will act as an in flight magazine, allowing users to read various articles, however the aircrafts do not have wifi so the users need to download the app in the boarding area and my goal is to then pre cache say the top 10 articles so they can read them during the flight.
Is this possible? and is PWA caching the right way to go about it? Has anyone does this sort of thing before?
Thanks in advance
To "convert" your website to an PWA, you just need few steps.
You need to know that the service worker is not running on the main thread and you cant access for example the DOM inside him.
First create an serviceworker.
For example, go to your root directory of your project and add a javascript file called serviceworker.js this will be your service worker.
Register the service worker.
To register the service worker, you will need to check if its even possible in this browser, and then register him:
if ('serviceWorker' in navigator) {
window.addEventListener('load', function() {
navigator.serviceWorker.register('/serviceworker.js').then(function(registration) {
// Registration was successful
console.log('ServiceWorker registration successful with scope');
}, function(err) {
// registration failed :(
console.log('ServiceWorker registration failed: ', err);
});
});
}
In vue.js you can put this inside mounted() or created() hook.
If you would run this code it will say that the service worker is successfully registered even if we havent wrote any code inside serviceworker.js
The fetch handler
Inside of serviceworker.js its good to create a variable for example CACHE_NAME. This will be the name of your cache where the cached content will be saved at.
var CACHE_NAME = "mycache_v1";
self.addEventListener('fetch', function(event) {
event.respondWith(
caches.open(CACHE_NAME).then(function(cache) {
return cache.match(event.request).then(function (response) {
return response || fetch(event.request).then(function(response) {
cache.put(event.request, response.clone());
return response;
});
});
})
);
});
Everytime you make a network request your request runs through the service worker fetch handler here first. You need to response with event.respondWith()
Next step is you first open your cache called mycache_v1 and take a look inside if there is a match with your request.
Remember: cache.match() wont get rejected if there is no match, it just returns undefined because of that there is a || operator at the return statement.
If there is a match available return the match out of the cache, if not then fetch() the event request.
In the fetch() you save the response inside the cache AND return the response to the user.
This is called cache-first approach because you first take a look inside the cache and in case there is no match you make a fallback to the network.
Actually you could go a step further by adding a catch() at your fetch like this:
return response || fetch(event.request).then(function(response) {
cache.put(event.request, response.clone());
return response;
})
.catch(err => {
return fetch("/offline.html")
});
In case there is nothing inside the cache AND you also have no network error you could response with a offline page.
You ask yourself maybe: "Ok, no cache available and no internet, how is the user supposed to see the offline page, it requires internet connection too to see it right?"
In case of that you can pre-cache some pages.
First you create a array with routes that you want to cache:
var PRE_CACHE = ["/offline.html"];
In our case its just the offline.html page. You are able to add css and js files aswell.
Now you need the install handler:
self.addEventListener('install', function(event) {
event.waitUntil(
caches.open(CACHE_NAME)
.then(function(cache) {
return cache.addAll(PRE_CACHE);
})
);
});
The install is just called 1x whenever a service worker gets registered.
This just means: Open your cache, add the routes inside the cache. Now if you register you SW your offline.html is pre-cached.
I suggest to read the "Web fundamentals" from the google guys: https://developers.google.com/web/fundamentals/instant-and-offline/offline-cookbook
There are other strategies like: network-first
To be honest i dont know exactly how the routing works with SPAs because SPA is just 1 index.html file that is shipped to the client and the routing is handled by javascript you will need to check it out witch is the best strategie for your app.
On latest react-native 0.60 onwards, the default app will include a list of links at landing page as below
Now if this react-native project running on simulator and we click on one of the link, it will open up on our laptop instead of opening on browser from within the simulator. I'm wondering how it works so I took a look at node_modules/react-native/Libraries/Core/Devtools/openURLInBrowser.js and found below code
'use strict';
const getDevServer = require('./getDevServer');
function openURLInBrowser(url: string) {
// Made a console.log here and getDevServer().url = http://localhost:8081
fetch(getDevServer().url + 'open-url', {
method: 'POST',
body: JSON.stringify({url}),
});
}
module.exports = openURLInBrowser;
Despite having this source code, I still can't understand how can we use a fetch library to launch a url in host's browser? So far I've only use fetch to perform http request from some backend but apparently there's something more that fetch is providing?
The Metro bundler is running on 8081. fetch is performing a HTTP POST request to http://localhost:8081/open-url. Metro is able to handle this request and open up the browser accordingly.
An example Express web server may handle it like so:
app.post('/open-url', req => {
const { url } = req.body;
// Handle code to open URL
});
I have the following sample code, in a nuxtjs/vuejs project
<template>
<v-app>
<div id="dibs-complete-checkout"></div>
</v-app>
</template>
<script>
export default {
head () {
return {
script: [
{ src: 'https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js' },
{ src: 'https://test.checkout.dibspayment.eu/v1/checkout.js?v=1' }
]
}
},
created () {
this.$axios.get('test/11').then((response) => {
var checkoutOptions = {
checkoutKey: response.data.checkOutKey,
paymentId: response.data.dibsPaymentId,
containerId: 'dibs-complete-checkout',
language: 'en-GB'
}
var checkout = new Dibs.Checkout(checkoutOptions)
checkout.on('payment-completed', function (response) {
})
checkout.on('pay-initialized', function (response) {
checkout.send('payment-order-finalized', true)
})
})
.catch((e) => {
console.error(e)
})
}
}
</script>
What is happening in there, is:
An external script from dibspayment.com is loaded
There is an axios call to the backend to return a checkoutKey and a paymentId, necessary in the checkoutOptions object
The script loaded from dibspayment.com contains an object, Dibs, which has a method called Checkout(checkoutOptions)
The development server is running on http.
I get several errors. One is "Dibs is not defined"
./pages/index.vueModule Error (from ./node_modules/eslint-loader/index.js):C:\git\ssfta_web\pages\index.vue 29:28 error 'Dibs' is not defined no-undefâś– 1 problem (1 error, 0 warnings)
Which is odd, because the page loads and is rendered inside the
Another error is
OPTIONS https://test.checkout.dibspayment.eu/api/v1/theming/checkout 401 (Unauthorized)
And the last error is
Access to XMLHttpRequest at 'https://test.checkout.dibspayment.eu/api/v1/theming/checkout' from origin 'http://10.0.75.1:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
I've tried:
Contacting DIBS payment support team, where responses are both slow and offer no real advice (providing me with a link to the top level FAQ page). I suspect that they use their sales department to answer inquiries.
running it on https, that made it worse
running it behind a nginx reverse proxy, which has an ssl certificate, the process running the code itself over http but nginx 'converts' (?) it to https
numerous hail maries that made everything worse
An image of the current situation
I don't really have a question, I just hope/suspect that I'm forgetting some basic configuration or detail that someone could spot
Any advice appreciated.
Had this issue this week.
Contacted Dibs Support with the issue, left work and the next day i returned to an email from support with a copy of my API-keys which i already had received, but after testing out my project again (Which had no changes) this error magically disappeared, so apparently this issue was something on their end. Assuming my keys were missing the proper authorisations.
Read the error message properly, it is an es lint error
Did this to solve it
/*eslint-disable */
var checkout = new Dibs.Checkout(this.checkoutData)
/* eslint-enable */