3

I come from an enterprise environment where I primarily work on internal web applications. I'm interested in doing some web development on the side, but I have a few questions regarding how things are typically done outside an enterprise.

At work, we usually develop in three different environments; Development, Test, and Production. Standard naming convention is <app name>-dev.<internal site>.com, <app name>-test.<internal site>.com, <app name>.<internal site>.com. Since the web sites are internal to our VPN, there is no big deal if a user stumbles upon the dev or test sites. On the other hand, if I ran into say, the stack overflow development page, I would see that as a possible security risk.

I would imagine a site like stack overflow would have a development site, and that it would be impossible for me to navigate to. There must be some way to access it though, for say, testers.

What are common ways to hide development sites from the public with exclusions for some people?

The only method I can think of is to host the non production sites on a VPN or something, but all that setup seems almost excessive for a smaller business. I am not looking for answers like "login screen".

Jeff
  • 2,283
  • 9
  • 32
  • 50
  • one solution I have used is a "magic cookie" that unless is present simply blocks or redirects the user. when registering a tester that cookie can get dropped (though does need a login). Other tricks include using hosts file to create DNS entries or require use of a specific proxy – Offbeatmammal Dec 06 '13 at 05:51

1 Answers1

0

As far as naming conventions, they're not super-standardized and it varies on the framework used. (Ex. in Rails you may have 'production', 'test', 'development')

Most of the time for development (and test) you don't need (or want) a publicly accessible web server. Just run it on a your own internal network. However you may need public access if your site needs things like webhooks called from other public sites (such as Salesforce), mobile devices outside a VPN etc. You can probably do most of your work internally and deploy to a public site for dev for those times you need it.

seand
  • 5,168
  • 1
  • 24
  • 37