I just installed LedgerSMB, but http://localhost/ledgersmb/login.pl says "Forbidden"

This seems a needlessly restrictive suggestion and is not helpful. The whole point of having a web-based app is to allow our collaborators/advisors/staff to have access to it from their variety of locations with appropriate usage permissions. How do our advisors and staff use lsmb with such restrictions? It is simply not practical for anything other than a sole operative making their own returns.

Rather than a simple reply here is some of the reasoning behind this choice for defaults.

This is an interesting area to discuss. There are many reasons why the default configuration is to "only listen to localhost", but LedgerSMB is not alone in this choice.

Many server programs, and some general client programs also, default to localhost.
Some examples of these would be

• postgres (at least under debian) which is our database server
• postfix - Mail Transfer Agent (installed by default on debian)
• mysql - another database server
• Transmission Web and remote control Interface (bittorrent client)
• Some VNC servers are also bound to localhost by default

The list is endless. What do they have in common?
Significant risk to your data or security if exposed to the big bad world without their configuration being customised to suit your specific environment.

While it may seem too rescrictive to start off being bound to localhost, it is generally considered good practice, as it encourages installers to learn a little about the security risks associated with any change they may make to open the connection possibilities to more locations.

For a site with a single user that is going to run the server on the same machine that they are using it from, the default will work just fine.

For a site where there will be multiple computers connecting to the server from the same network, you need to allow access from either a list of addresses on the local network, or any machine on the local network.
The choice between only some, or all machines will depend greatly on the trust level of devices and users on the network.
A business that has only a small number of admin staff, but a large number of low payed workers (eg: a call center providing uncharged anonymous support for kitchen appliances) would want to limit which of the hundreds of computers present on the network can connect to LedgerSMB. (yes this can be done at a network infrastructure level, but there may be reasons preventing that choice)
On the other hand, if the trust level is high and most staff need access to LedgerSMB it is likely you would allow connection from any address on the local network (possibly excluding the modem/router).

Access from a remote location (outside the internal network) is a completely different problem and decisions here must be made very carefully.
Some of the choices are:

• Use a VPN to allow an external user to connect to your local network as if they were physically on the network. This requires a high level of trust as that user then has full access to anything that could be done if they were inside the building.
      * dump an endless full color print job to yousersur expensive printer
      * read/write/delete any accesable file shares
      * introduce a virus or trojan
      * the list goes on
• Use a VPN to provide direct access to the LedgerSMB server but not the business network
  Once again this requires a high level of trust, any accessable resources on that server can be used by that external user. This is generally safer than giving users access to your entire network, but can still be a risk if the server supports more than just LedgerSMB
• Use SSH to provide a secure login and tunnel just to the port that LedgerSMB is running on
  This both allows a secure encrypted connection and limits the users access to only the ports that you set up for forwarding, it also means that they connect (on their machine) to something like
  https://localhost:8001
  rather than https://yourserverIPaddress/
  This can help to further reduce risk by minimising information like your internal network address range from being leaked.
• Of course with any and all of these options it is strongly recommended that you never deploy a server containing sensitive information unless it is running https to provide end to end encryption. Keep in mind, https is not infallible, Man In The Middle (MITM) attacks are possible, although LedgerSMB does what it can to reduce the risks, they can't be eliminated.

A final type of installation requires an even more critical eye for security and detail.
Any installation that is to be directly exposed to a public network, whether it be the internet, or a public wifi connection (do you have LedgerSMB installed on your laptop while you are using wifi at your local coffee shop?)
In this case anyone that can potentially connect to your server/computer/laptor could attempt to attack your presumably Mission Critical financial data.

These risks are why the default is to limit access to localhost, even if you are on a public wifi network with LedgerSMB installed on your Laptop, no-one on that wifi network can even see your LedgerSMB installation (unless they have already completely hacked your machine)
 

None, of the above choices are easy to make, and are often hard to implement correctly if you care about security at all.

Perhaps we need to relax the default recommendation a little and improve the documentation to show how to configure with a whitelist of computers that are allowed to connect, but this gets tricky for most small to medium networks that use nothing more complex than their modem/routers dhcp server to provide IP addresses. It is hard to setup a whitelist if the addresses may change over time.

Of course it is entirely reasonable that we include (and it is already there) documentation on how to allow any address on your local network to have access.

In the coming year there is going to be a significant effort to improve the Installation experience, and the development team will be discussing aspects of how that can be done on the mailing lists. Please join in with your suggestions as these discussions occur, we rely on input from our users and people supporting our users (for example those doing installations) to show us where we can improve

Personally I am working on a set of installer scripts that will help automate the installation, not only of the LedgerSMB software, but also other elements of the server by user request. Things like setting up a simple MTA so that LedgerSMB can send emails, automatic configuration of printers, and many other things are on the drawing board for these scripts.
Of particular interest to you, may be the ability to choose, during the installation, what LedgerSMB will bind to, localhost or one or more (if available) of the configured networks.

I hope this has helped you understand some of the reasons why this is the default.
Changing the configuration to allow more machines to connect is not especially difficult, it's a single file to edit and only a couple of changes, but does need to be done with some knowledge about the risks.

Regards
David G