I am using SPA (Laravel and Vuejs). When in development, website project worked perfect but when after running npm run production and put it on live server, I got errors saying
Access to Xmlhttprequest at http://localhost:8000/auth_check from origin https://hamariweb.com/auth_check has been blocked by Cors policy.
I have tried different solutions that fixed their problems but not mine. I want to know what is wrong with it and how can I fix it?
Sounds like somewhere in your code you're trying to send a request to http://localhost:8000/auth_check which isn't going to work in prod. You need to find the call to that URL and replace it with a call to the correct URL.
You can create an ENV setting in your .env file like this.
APP_URL=https://hamariweb.com
Then share that env file to your javascript code like this.
MIX_APP_URL="${APP_URL}"
Any ENV settings that start with MIX_ are passed to Javascript and this is passing it the initial APP URL value.
To finally grab the app url in the JS do this:
process.env.MIX_APP_URL
You can even assign the entire env settings globally like this.
if(process && process.env){
window.env = process.env;
}
Any .env MIX_ variables will be available in window.env at that point and in your SPA you'll be able to make the URL or any other variable configurable based on environment.
Related
So I tried creating a new project using Breeze+vue in Laravel.
I was following this guide: https://www.youtube.com/watch?v=A7UlfXPhsaA
When I finally got vite running on npm run dev without issues, I came across the app_url and I tried to change it to something similar like in that guide (timestamp 6:14 in video), in my case the app_url value was just http://localhost and I changed it to http://grandia.test.
And it reflects like that when vite is running:
VITE v3.1.0 ready in 1031 ms
➜ Local: http://localhost:5173/
➜ Network: use --host to expose
LARAVEL v9.28.0 plugin v0.6.0
➜ APP_URL: http://grandia.test
but nothing happens when I go to the site. only the localhost:5173 works properly.
I tried googling for answers but I couldn't find anything helpful.
Could someone help me out what I'm doing wrong or missing? Thanks!
I had the same issue, It look like you changed URL: http://grandia.test instead of localhost. So you should try with npm run build instead.
Changing Laravel’s APP_URL parameter will not magically allow you to choose the URL your website is served at. It will only tell Laravel what it should use when generating URLs related to your website.
The video’s author uses the Laravel Valet local development environment. It provides a park command that allows you to automatically serve the subfolders of some folder (e.g. Sites in the video) at http://<subfolder>.test.
In the video, the project is created in Sites/reddit-clone/, which makes it possible to directly access it at reddit-clone.test.
My Laravel site uses SoapClient to access another site during an page load (with performs about 6 seconds of data processing before the soap call.) I noticed sometimes the SoapClient switches to non-wsdl mode and the process errors out. I discovered this was happening because the SoapClient was passed a NULL for its first constructor parameter (the URI of the WSDL file). I though this was strange, because this value came directly from the .env file. The site was having no trouble connecting to the database, so the .env file had to be working. I set up a function that access .env variables repeatedly during the page load, using env(...). During a Soap error, I discovered around the four second mark, the site lost access to the .env vars. Before that point, the information was accessible. After that point, calls to env() returned NULL. This may be related to other page request (possibly repeat calls to the same page, requesting the same process.) Also, I just upgraded php to 7.4.13 (xampp with 64 bit thread support: php-7.4.13-Win32-vc15-x64.) Has anyone seen this before, and has a way to address this issue?
EDIT ====
The SoapClient was created in a model, and the env() function was used to access the environmental vars. I have learned that env() should not be used anywhere but config files. This may explain my problem.
I have never seen this problem. But an approach might be to load env variable into a config variable and use that instead. For example: create extra.php file in the config directory like this:
<?php
return [
'api_url' => env('API_URL'),
];
And use it like this:
config('extra.api_url');
// Instead of env('API_URL')
Hope it works.
I' trying to execute the OAuth 2.0 PKCE demo with a VueJs app outlined here:
https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce
https://github.com/oktadeveloper/okta-auth-js-pkce-example
Once in the Heroku App I have these Environment Variables:
Everything appears to be running fine except for the fact that the variables OKTA_CLIENT_ORGURL and OKTA_OAUTH2_ISSUER were refering to an incorrect dev-XXXXXX address, the correct one is the one shown on the picture (dev-371167), before it was someone else's url (dev-739491) for some reason.
The problem is that after making the changes shown in the image to the correct dev url, it's still making the calls to the old dev-739491 url.
Heroku doesn't seem to be refreshing or making the desired changes in the app.
Am I missing an option to refresh? Is it possible to rebuild so it reads the new changes? Could the problem be in the code/build itself?
Thanks.
EDIT: As per the suggestion in the comment I turned the app off then on again and it still didn't make the changes.
This is what my screen looks like:
EDIT 2: I have since deployed the same app two more times and reading the build logs it assigns a random CLIENT_ID and URls. Each deployed app has a different pair of these. I don't know where they come from.
I wrote the Okta Heroku Add-On. I'm looking into the behavior you're seeing.
When you change the environment variables, heroku should restart your app automatically.
So, the two issues are that the environment variables didn't match you saw in Heroku didn't match with what you expected them to be and that the app doesn't seem to be picking up on the environment variables.
How did you know that dev-371167 was the correct org and that dev-739491 was incorrect?
When you say you deployed the app two more times, what exactly are you doing to deploy? Are you using the Heroku cli?
Laravel allows you to acess .env variables in javascript by prefixing the app with MIX_, my file looks like this:
APP_NAME="My app"
MIX_APP_NAME="${APP_NAME}"
This works in development, however when I build the app for production the app name shows up as undefined. Is there some way to get around this issue?
I use docker as my local dev environment and use the dinghy-http-proxy which adds a new TLD .docker to map request to a nginx-proxy container.
My websites are typically reached through an URL like http://devel.domain.com.docker.
I want to use ngrok to develop locally while accessing remote webhooks.
I successfully launched ngrok with the command:
ngrok http -host-header=rewrite devel.domain.com.docker 80
I can access the login form of my web application through the address http://randomsubdomain.ngrok.io.
However, I can't log in because it looks like the cookie session can't be set.
Indeed, cookies sessions are tried to be set for the domain devel.domain.com.docker but as we use randomsubdomain.ngrok.io in the browser they are blocked for security reasons.
How can I bypass this problem? Am I missing something in my configuration? Is ngrok the right tool for what I want to achieve?
Asked directly to ngrok.io support and got this answer:
No, you're not missing anything, that's just an unfortunate side effect of rewriting the host header. Host header rewriting only works for some applications because of complications like this (and others that involve javascript and cross-origin, etc). If possible, it's always much better to reconfigure your website to accept the ngrok.io host header.
However, I found a solution by checking if the request contains in the header x-original-host the domain ngrok.io, and then I alter the session mechanism (in PHP session_set_cookie_params) to use the x-original-host domain instead.
As mperrin said you have to alter php cookie session mechanism.
Reading from session_set_cookie_params:
Set cookie parameters defined in the php.ini file.
The effect of this function only lasts for the duration of the script.
Thus, you need to call session_set_cookie_params() for every request
and before session_start() is called.
The most important argument is $domain and to make ngrok work equally decent you can also use before session_start() the command ini_set() (see ini_set): ini_set('session.cookie_domain', 'xxx.ngrok.io');
It also took me hours to resolve for my custom hosting php platform but I knew that my auth subsystem should work under a valid hostname apart from localhost so I focused in how the cookies are set from my code.
Such kind of php environment settings should be set early by any decent php framework and that was one of my primary goals when I started building it (in my case I only have to change the value in a json text file at the server).