bobclewell's avatar

How do I make a custom local domain for Laravel Herd projects?

I've moved to Laravel Herd from an old school Vargrant / Homestead local dev environment. In my previous environment the domain was domain.local, but in Herd it's domain.com.test.

How can I setup a redirect or customized Herd so that I can continue to use domain.local?

1 like
21 replies
Snapey's avatar

is it that important, or just a temporary annoyance?

Snapey's avatar

command line; herd domain local

1 like
SaidGuerrero's avatar

@snapey that command is not longer supported and broked all my sites. I had to uninstall and reinstall to fix it, but still having the same issue, i have to change the local dns… from .test to .custom.some.else

willeums's avatar

@bobclewell and @saidguerrero If your using Herd, when you try to change your tld for your local projects or use the command herd tld [ your custom local tld ] you will get a message as such Using a custom TLD is no longer officially supported and may lead to unexpected behavior Do you wish to proceed? [y/N] . Herd recommends that you use the *.test domain or tld for this reason.

Since herd is built on top of Valet, and doesn't modify the existing installation on your system you can do pretty much the same thing above to get a custom tld with Valet. You will need to stop Herd services, restart Valet valet restart and then use the Valet command valet tld [the tld you would like to use ] . Hop in your browser and see the results of your local custom tld *.your-tld

However, right now it seems redundant to have both since they pretty much do the same thing and the tld *.test is a minor inconvenience if you are used to having a custom tld , since you don't have to deal with homebrew and all it's dependencies and setting up composer , node and the laravel/installer.

Additionally, the only thing you may need is a built-in database server. In this case, you can check out DBngin and perhaps this tutorial. I hope this helps and provides more clarification. Take care.

1 like
Snapey's avatar

Best practice is that NOTHING in your project should know or care what your domain name is so changing the TLD is purely for the convenience of the developer when they first load the site.

The reason its set at .test and is not advised to change is that this is a domain that you should never need to reach out on the Internet

https://en.wikipedia.org/wiki/.test#

1 like
jeffshaikh's avatar

@Snapey I agree with most of what you are saying. Problem is I'm doing development with Google APIs and I can't setup a dev environment for those APIs . These are JS APIs so no server side API or callbacks required. Just Google APIs doesn't allow a .test TLD, I can't do local dev with Socialite. Any recommendations for local dev with socialite?

9 likes
rander's avatar

@Snapey Revisiting this old thread to just comment that yes, that is best practice, but when you are working with external partners, you don't always have the luxury to dictate that yourself. I'm going to have to stop using Herd because of a new requirement that we don't have control over.

rander's avatar

@ghabe Thank you for the heads up @ghabe, I got alittle optimistic for a sec, but it's not going to work unfortunately. Without getting into specifics, I'm dealing with cookies and CNAMEs and so stuff like this is just not going to work.

I only mention it to ask that people remember that 'best practices' sometimes juts up against the annoying limitations of the real world, with different organizations, legacy systems, integrations between systems with different decision makers, etc etc

1 like
bobclewell's avatar

@snapey Thanks for the education on the .test top level domain. The project that I maintain used .local as it's top level development environment domain, but I can see in the Wikipedia reference that is a bad practice, since .local has its own special use case.

en.wikipedia.org/wiki/.local

Or course, .dev would also make more sense to me here than .test, but again that's taken. So, considering the foundation established by the IETF, .test is the best choice here.

Brimestone's avatar

Bumping this. It would be great to be able to control the domain for testing purposes, particularly for Laravel/Socialite

4 likes
xpf0000's avatar

Laravel Herd may have its own design. Try to prevent users from modifying the site's domain name, nginx configuration file, etc. To ensure maximum stability. You can try PhpWebStudy. Another PHP environment tool. Supports any domain name. Everything, all under your control.

LazyDali's avatar

Hello, I am also experiencing an issue with Google Auth redirect due to the .test TLD which is rejected.

I use this as the callback url : h t t p : / / localhost/JUMP/my-project.test/auth/google/callback

(* the weird h t t p : / /. is intentional here in the forum as it would not let me add a link in my first post)

I just realized the url rewrite from the .htaccess won’t work because .htaccess is used by Apache. So I need to find a way to do the redirect url rewrite directive in a nginx conf file for my local app.

Any guidance on how/where to add a rewrite directive would be greatly appreciated. Thanks!

/=====/

Here's what I finally did to make it work:

Note : the weird spacing in the url is because Laracasts prevents me from including links as I am new to the forum.

#1) Added my Google API callback and my local development domains to the /etc/hosts file:

127.0.0.1	local . fakedomainxyz . com    // sorry for the weird spacing...
127.0.0.1	my-project . test    // sorry for the weird spacing...

#2) Defined the redirect url in Google API Console: h t t p s : // local . fakedomainxyz . com/auth/google/callback // sorry for the weird spacing...

#3) Made sure the Google API callback url is the same in my project .env file

#4) Ensured my project directory is in the parked Herd directory

#5) Set herd secure in my local project directory (or you can also set it via the GUI)

#6) Inside the nginx config file .../Herd/config/valet/my-project.test, under the first server block (for http / non-ssl), I added a ssl server block as:

server {
    listen 127.0.0.1:443 ssl;
    server_name local . fakedomainxyz . com;    // sorry for the weird spacing...
    rewrite ^/(.*)$ h t t p s : // my-project . test/ permanent;    // sorry for the weird spacing...
    ssl_certificate "/Users/[your name]/Library/Application Support/Herd/config/valet/Certificates/[your local app domain].crt";
    ssl_certificate_key "/Users/[your name]/Library/Application Support/Herd/config/valet/Certificates/[your local app domain].key";
}

You can replace the 2 ssl_certificate lines with the one you can find in the default ssl server block below in the file.

Note: I decided to create the ssl server block above the existing one because nginx seem to go through the whole file following each block conditions so I thought it would be better to isolate my ssl block with the server_name that is only used during the Google callback so it should be skipped for any call that is not using this fake redirect domain.

#7) I ensured to restart the services from Herd and flushed all browser cache and cookies.

#8) In my app, after I log in, I get a warning that the certificate is not secured but this doesn't matter as I only access it from my local development on my machine.

bobLoblaw's avatar

I struggling with the same issue as everyone above. I'm wondering if expose.dev from the Tinkerwell people would be a fix for this problem? Their docs say you can use it to "publicly accessible endpoint for the 3rd party application". Kinda seems like this would be a a fix. Thoughts/feedback, feelings, suggestions?

UPDATE: Nope. At least not the free version. It's not a big enough problem for me to pay for. Still interested in other suggestions from the group though.

Snapey's avatar

@burnt_toast Expose should do what you want.

The point is, the herd imposed test domain is irrelevant for webhooks and callbacks because you can never route to internal urls without a forwarding service like NGROK or Expose

codemountain's avatar

or perhaps use a .com redirect service to configure your Callback url dev console as "https://redirectmeto.com/https://<YOU-FOLDER>.test/login/google/callback"

LazyDali's avatar

@codemountain I don't know for other people but my issue was not being able to rewrite the redirect url after the redirect. I could finally figure out the nginx syntax.

bobLoblaw's avatar

For anyone still interested, I did finally get this working using Herd, Socialite, and Expose. Add the full Expose url with your callback to Authorized redirect URIs in your GCP Client ID for Web application. The GOOGLE_REDIRECT_URI in your .env should match exactly. Both settings should look something like https://ypk29e4a83.sharedwithexpose.com/auth/google/callback.

There are, of course, still issues with the whole keep-alive thing because it looks like you get a 1 hour timer when you start Expose. But still, good enough for testing.

Easy peasy. Lamb and sneezy. Hope this helps.

1 like
twlatl's avatar

The lack of ability to use a custom domain is a huge drawback to our team using Herd.

First off, we have fonts that are whitelisted to work only on certain domains, and *.test isn't one of them.

Second, there are CORS restrictions that have similar whitelisted domains restrictions. Expose can probably solve some of these issues, but that's another configuration and another license.

Herd seemed like a slam dunk for teams development needs (we are a Laravel shop), but I'm thinking Mamp Pro might be better suited (and $10 cheaper/year).

Please or to participate in this conversation.