Bloquear alteração do proxy no Firefox

Bloquear alteração do proxy no Firefox
Para impedir que usuários alterem a configuração do proxy vamos ao passo a passo:

Acesse a pasta “C:\Program Files\Mozilla Firefox”

Crie o arquivo “mozilla.txt”

Dentro do arquivo insira as seguintes linhas
lockPref(“network.proxy.backup.ftp”,”192.168.0.1″);
lockPref(“network.proxy.backup.ftp_port”,3128);
lockPref(“network.proxy.backup.socks”,”192.168.0.1″);
lockPref(“network.proxy.backup.socks_port”,3128);
lockPref(“network.proxy.backup.ssl”,”192.168.0.1″);
lockPref(“network.proxy.backup.ssl_port”,3128);
lockPref(“network.proxy.ftp”,”192.168.0.1″);
lockPref(“network.proxy.ftp_port”,3128);
lockPref(“network.proxy.http”,”192.168.0.1″);
lockPref(“network.proxy.http_port”,3128);
lockPref(“network.proxy.no_proxies_on”,”localhost, 127.0.0.1″);
lockPref(“network.proxy.share_proxy_settings”,true);
lockPref(“network.proxy.socks”,”192.168.0.1″);
lockPref(“network.proxy.socks_port”,3128);
lockPref(“network.proxy.ssl”,”192.168.0.1″);
lockPref(“network.proxy.ssl_port”,3128);
lockPref(“browser.startup.homepage”,”http://www.google.com.br/”);
lockPref(“network.proxy.type”,1);

Altere “192.168.0.1” para o endereço de seu proxy, mas mantenha as “”.
Altere “http://www.google.com.br/” para uma página padrão de sua preferencia mas mantenha as “”.

Agora que temos o .txt precisamos transforma-lo em .cfg, nas versões mais antigas do firefox era somente renomear as extensões e pronto, nos mais novos precisamos passa-lo por um conversor.

Para isso acesse http://www.alain.knaff.lu/howto/MozillaCustomization/cgi/byteshf.cgi, na segunda opção onde aparece “Upload mozilla.txt to get mozilla.cfg (byteshift 13)” clique em “Selecionar arquivo” e selecione o mozilla.txt que criamos e clique em “Convert mozilla.txt to mozilla.cfg”

Pronto agora temos o mozilla.cfg configurado.

Para finalizar temos que “obrigar” o navegador a usar essa configuração para todos os usúarios.

Abra a pasta “C:\Program Files\Mozilla Firefox\defaults\pref”, crie um arquivo chamado all.js edite ele e insira as seguintes informações:
pref(“general.config.filename”, “mozilla.cfg”);
pref(“general.config.obscure_value”, 13);

Em alguns casos precisei reiniciar a máquina para funcionar.

Pronto abra o navegador e você verá que o proxy esta configurado e não tem como alterar as configurações.

Automatic Proxy Configuration via DHCP

Para evitar a configuração manual demorado de um servidor proxy em todos os computadores, telefones e tablets, a configuração do proxy pode ser fornecido automaticamente via DHCP usando WPAD .

Para esta configuração, são necessários os seguintes componentes:

Um servidor DHCP que anuncia a opção de DHCP 252 com a URL do PAC arquivo (wpad.dat).
Um servidor web que serve o arquivo wpad.dat
Um arquivo PAC wpad.dat onde o IP Proxy é definida

Em um sistema MikroTik, a configuração do servidor DHCP se parece com isso:

/ Opção dhcp-server ip
adicionar código = 252 name = locais-pac-servidor value = ” ‘http: //192.168.0.2:80/wpad.dat’ ”
/ Network dhcp-server ip
adicionar o endereço = 192.168.0.0 / 24 dhcp-option =-pac-servidor local dns-server = 192.168.0.1 do gateway 192.168.0.1 = máscara de rede = 24

Por favor, note que o questionmark à direita na URL para o arquivo PAC. Esta é uma solução para mais uma ocorrência de RFC picuinhas onde algumas implementações podem interpretar mal a opção DHCP e adicione um caractere NULL-byte codificado para o final da URL ao solicitar o arquivo PAC do servidor web.
Com o questinmark no final da URL, qualquer personagem adicional NULL-byte será ignorado pelo servidor eo arquivo PAC será carregado apenas multa.

Seguindo o exemplo acima, no 192.168.0.2 máquina, servimos o seguinte arquivo wpad.dat:

FindProxyForURL função (url, host) {
retornar “PROXY 1.2.3.4:8080; DIRECT”;
}

Com esta configuração, todos os sistemas vai usar o proxy no 1.2.3.4 e se o proxy não está disponível tentar se conectar diretamente à Internet.
Enquanto isso é bom para uma rede doméstica, onde o proxy é usado principalmente para AdBlocking, você provavelmente vai querer remover a parte direta em uma configuração empresarial.

Usando o Thinstation como cliente do Terminal Server

O Thinstation é uma distribuição GNU/Linux, desenvolvida para thin client ou equipamentos antigos. Ele pode se conectar a um servidor remoto ou que utilizar recursos locais, para conexões remotas. O Thinstation permite a utilização do NoMachine NX, VNC, Microsoft Windows Terminal Services (RDP), VMWare View Open client, X, telnet, SSH, entre outros.
Para utiliza-lo como cliente do Terminal Server do Windows, é necessário configurar o Windows Terminal Server. (Como configurar um servidor de terminal).
Para configurar o Windows para boot pela rede será necessário usar um programas de terceiros, já que o Windows não fornece servidor TFTP. Recomendo o TFTPd32. Para saber como configurar o TFTPd32 acesse meu outro post.
Em seguida deve-se baixar o thinstation, para isso acesse o site http://tsomatic.agarwal-associates.com

O TS-O-Matic é um site onde você pode criar uma versão personalizada do thintation. Como ele, pode-se selecionar apenas os aplicativos que se deseja utilizar. Utilizaremos a configuração padrão, pois ela já inclui o cliente do terminal server.
Clique no icone Build
Aguarade até que ele construa a imagem. ao concluir você terá a opção de editar o arquivo de configuração.

Esse arquivo de configuração ficará armazenado dentro da imagem e será usado quando não encontrar outros arquivos de configuração. Você acrescentar as linhas a seguir no final do arquivo:

SESSION_0_TITLE=Icewm
SESSION_0_TYPE=icewm
SESSION_0_AUTOSTART=ON

Clique no icone Write Image para continuar e aguarde até que o processo de construção da imagem concluir.
Primeiro, você deve baixar o arquivo de configuração. Clique em Build e baixe o thinstation.conf.example, renomei-o para thinstation.conf.network e colque na pasta do servidor TFTP. Este é o arquivo de configuração do Thinstation, qualquer alteração da configuração deve ser feita nele.
Para baixar a imagem gerada, clique em PXE e baixe os arquivos initrd, vmlinuz, pxelinux.0 e default e colocá-los dentro da pasta do servidor TFTP. Em seguida, crie uma pasta chamada pxelinux.cfg e coloque o arquivo default dentro dela.
Configure no servidor DHCP o arquivo de inicialização para pxelinux.0.
Pronto! Seu servidor já está configurado para inicializar o Thinstation pela rede. Quando ele estiver executando basta clicar no icone MSWindows para acessar o Windows Terminal Server (ou o MS Windows [fs] para abrir em tela cheia).

Dica: Para iniciar automaticamente já abrindo a conexão remota você pode mudar o valor de SESSION_0_TYPE para rdesktop e usar o parametro SESSION_0_RDESKTOP_SERVER para definir o ip do servidor.

Servidor Linux: Configurando Zonas de DNS e VirtualHosts no Apache 2

Iremos configurar as zonas de domínios e sub-domínios, e fazer com que o Apache 2 responda por esses domínios no ambiente WEB. Em suma, o que vou demonstrar é como configurar o domínio nossoserver.com, o sub-domínio guarani.campeaobrasileiro.com.br e fazer com que através do navegador consigamos acessá-los pelos endereços http://www.nossoserver.com e http://guarani.campeaobrasileiro.com.br.

O processo aqui descrito é basicamente o mesmo apresentado na documentação oficial do Ubuntu Intrepid Ibex (Ubuntu 8.10), na seção de configuração do BIND. Porém gosto de entender cada linha e cada parâmetro configurado, então tentei deixar o mais detalhado possível, explicando em detalhes a configuração do arquivo de zona e os principais tipos de registro DNS. Finalizarei com as configurações para o Apache 2, que por sinal, são bem simples.

Adicionando uma zona Primary Master

Vamos editar o arquivo /etc/bind/named.conf.local para inserirmos as informações da zona de DNS.

# vi /etc/bind/named.conf.local

Basta inserir as linhas abaixo lembrando de substituir o domínio nossoserver.com pelo domínio de sua escolha.

zone "nossoserver.com" {
type master;
file "/etc/bind/zonas/db.nossoserver.com";
};

Entendendo cada linha:

  • zone – onde deverá ser inserido o nome do domínio, no nosso caso nossoserver.com;
  • type – o tipo de configuração da zona, em nosso caso é master, pois o responderá de forma autoritária por todas as consultas feitas ao domínio. Outros tipos são: forward, hint, slave (utilizado para configuração em servidores secundários de DNS), stub e delegation-only. No final deste post, na seção fontes, é possível acessar um link que detalha cada um dos tipos;
  • file – caminho do arquivo de configuração da zona de de DNS.

Após inserir as linhas, salve o arquivo (:wq!).

A melhor forma de configurarmos o arquivo de zona é utilizando o modelo fornecido pelo próprio BIND no arquivo /etc/bind/db.local. Então vamos criar o diretório onde ficarão as zonas (por questão de organização eu coloco em um diretório em separado, no caso o diretório se chama zonas) e copiar o modelo:

# mkdir /etc/bind/zonas
# cp /etc/bind/db.local /etc/bind/zonas/db.nossoserver.com

Agora vamos editar o arquivo db.nossoserver.com:

# vi /etc/bind/zonas/db.nossoserver.com

Você deverá alterá-lo deixando-o como abaixo:
;
;BIND data file for local loopback interface
;
$TTL 86400
@ IN SOA zenon.nossoserver.com. root.nossoserver.com. (
2009041701 ;Serial
43200 ;Refresh
900 ;Retry
2419200 ;Expire
3600) ; Negative Cache TTL
;
@ IN NS zenon.nossoserver.com.
@ IN A 192.168.0.2
zenon IN A 192.168.0.2
careca IN A 192.168.0.4
www IN CNAME careca.nossoserver.com
bozo IN A 192.168.0.1

 

Faça as alterações conforme suas configurações locais.

Antes de entendermos cada linha, vale avisar que o ponto-e-virgula deve preceder comentários.

Entendendo cada linha:

  • $TTL – (time-to-live) é o tempo, em segundos, que a informação da zona DNS deverá ser armazenada em cache, ou seja, os servidores que armazenaram as informações da zona, deverão considerar a informação válida apenas dentro do período TTL e caso seja necessária uma nova consulta e o TTL já tenha expirado, então o servidor DNS deve ser consultado novamente. O tempo recomendado pela RFC 1912 é de um dia. Se o TTL for zero, então a informação não será armazenada em cache;
  • SOA – é a linha de definição da autoridade do domínio. Define o nome da zona, servidor de DNS e e-mail do responsável. Possui cinco colunas:
Nome Classe RR Nome do Servidor E-mail do responsável
@ IN SOA zenon.nossoserver.com. root.nossoserver.com.
  • Nome – normalmente utiliza-se @, pois é a referência ao nome original da zona definido (em nosso caso) no arquivo /etc/bind/named.conf.local;
  • Classe – historicamente existem mais duas opções HS e CH, porém são padrões do MIT e não são mais utilizados, portanto deve se utilizar IN como referência a Internet;
  • Nome do servidor – parâmetro MNAME referente ao nome do servidor DNS e deve ser finalizado por ponto “.”;
  • E-mail do responsável – parâmetro RNAME que indica o e-mail do responsável pela zona.
  • Serial – deve ser incrementado a cada alteração no arquivo de zona, por isso que deixei como 1. Porém alguns administradores de rede preferem deixar a data da última alteração, por exemplo 2009041701, ou seja 17/14/2009 e 01 por ser a primeira configuração. Servidores secundários fazem a atualização da sua configuração caso o valor seja aumentado;
  • Refresh – informa ao servidor secundário de DNS quando deverá ser atualizada a informação da zona. Também é configurado em segundos e o recomendado é doze horas, ou seja 43200 segundos;
  • Retry – define o tempo entre cada tentativa (sem sucesso) de contato entre o servidor de DNS secundário e o primário. Também definido em segundos e o tempo recomendado é de três a quinze minutos;
  • Expire – usado apenas por servidores de DNS secundário. Tem como função indicar quando o servidor secundário parará de responder pela zona e contatará o servidor principal;
  • Negative Cache TTL – tempo que um erro de DNS fica em cache. (Sinceramente não consegui concluir o objetivo deste parâmetro).

Os tempos definidos na configuração de SOA não precisam ser escritos diretamente em segundos, o que reflete em menos uso de calculadora. Você pode utilizar letras como atalhos da configuração. Explicando melhor: No TTL quando definimos 86400 segundos, ou seja, 1 dia, então poderíamos ter configurado como 24H ou 1D, para o Refresh que definimos como 43200 segundos, ou seja, 12 horas, poderíamos ter colocado 12H.

Registros do DNS

Além da configuração básica da zona, também é necessário configurar os demais registros do DNS. É importante destacar que a estrutura aplicada aos demais RRs (resource records) é o mesmo da definição do SOA.

Em nosso caso, a linha registro zenon IN A 192.168.0.2 faz com que todos as máquinas que utilizem este servidor DNS possam acessar a máquina zenon.nossoserver.com apenas com um a palavra zenon, pois foi mapeada com o RR A para o IP 192.168.0.2. Já o registro www é necessário para que configuremos o domínio http://www.nossoserver.com para que responda no servidor careca.nossoserver.com. Então foi mapeado para o servidor 192.168.0.4.

Repare que as últimas duas linhas de registro são referência aos demais servidores, ou seja, o servidor WEB chamado de careca.nossoserver.com e o gateway que foi chamado de bozo.nossoserver.com. Cada um deles foi mapeado para seu IP.

Principais tipos de registros DNS

Existem outros tipos de registros, porém os mais comuns são A, MX, CNAME e NS:

  • A – faz o mapeamento de um nome à um IP em formato IPv4. Exemplo:
    www IN A 192.168.0.2
  • CNAME – faz o mapeamento de nome (apenas de nomes) para o nome do servidor. Exemplo:
    web IN CNAME www.nossoserver.com.
  • MX – especifica o nome e a preferencia do servidor de e-mail. Exemplo:
    IN MX 10 mail.nossoserver.com.
    mail IN A 192.168.0.100
  • NS – aponta qual é o servidor que responde pelo domínio. Exemplo:
    @ IN NS zenon.nossoserver.com.
  • PTR – utilizado na configuração do dns reverso (veremos mais abaixo) mapeia um IP a um nome, ou seja, faz o papel inverso do tipo A. Exemplo:
    2 IN PTR www.nossoserver.com
  • SRV – tentando ser bem sucinto, a função deste registro é mapear serviços e é utilizado por serviços de diretórios como o LDAP. Voltaremos ao assunto no próximo post quando trataremos da integração entre o Active Directory e o Bind. Por hora, acesse o link com maiores detalhes: http://www.zytrax.com/books/dns/ch8/srv.html.

Configurando a zona reversa

Primeiro vamos entender o que é e pra que serve a zona reversa de DNS. Zona reversa tem como objetivo revelar o nome de um host a partir de um IP. Ou seja, é baseado no tipo de registro PTR.

A criação da zona reversa segue o mesmo procedimento da criação do arquivo de zona, onde o registro SOA tem a mesma configuração de uma zona “normal”. A única diferença é relativo aos registros PTR, onde devemos mapear um IP para um nome (host name). Então vamos utilizar o próprio arquivo de zona como modelo.

Vamos copiá-lo e editá-lo:

# cp /etc/bind/zonas/db.nossoserver.com /etc/bind/zonas/db.192
# vi /etc/bind/zonas/db.192

O código deverá ficar como abaixo, porém é necessário que você faça as alterações conforme suas configurações:

;
;BIND data file for local loopback interface
;
$TTL 86400
@ IN SOA zenon.nossoserver.com. root.nossoserver.com. (
2009041701 ;Serial
43200 ;Refresh
900 ;Retry
2419200 ;Expire
3600) ; Negative Cache TTL
;
@ IN NS zenon.
2 IN PTR zenon.nossoserver.com.
4 IN PTR careca.nossoserver.com.
1 IN PTR bozo.nossoserver.com.

Agora basta salvar o arquivo e reinicializar o serviço BIND:

# /etc/init.d/bind9 restart

Verifique qualquer ocorrência no log com o comando:

# cat /var/log/syslog | grep named

Testando as configurações

Para testar se as configurações estão corretas, antes mesmo de reinicializar o serviço BIND, basta utilizar os comandos abaixo:

# named-checkzone nossoserver.com /etc/bind/zonas/db.nossoserver.com
# named-checkzone nossoserver.com /etc/bind/db.192

Os resultados devem aparecer como estes:

zone nossoserver.com/IN: loaded serial 2
OK

zone nossoserver.com/IN: loaded serial 1
OK

A ferramenta named-checkzone é muito útil para validarmos e verificarmos se nossos arquivos de zona estão configurados corretamente com o domínio definido.

Depois de reinicializado o serviço BIND, você poderá testar suas configurações de DNS com os comandos:

# ping nossoserver.com
# dig axfr nossoserver.com

Configurando um sub-domínio

Agora vamos adicionar o sub-domínio guarani.campeaobrasileiro.com.br. O processo é bem simples e caso você tenha lido com atenção as informações acima, você não precisará dedicar muito tempo a esta parte do tutorial.

Primeiramente vamos editar o arquivo /etc/bind/named.conf.local e adicionar as linhas abaixo:

# vi /etc/bind/named.conf.local
zone "guarani.campeaobrasileiro.com.br"{
type master;
file "/etc/bind/zonas/db.guarani.campeaobrasileiro.com.br";
};

Após salvar o arquivo, então vamos criá-lo no diretório zonas e deixá-lo como o exemplo abaixo:

# vi /etc/bind/zonas/db.guarani.campeaobrasileiro.com.br

;
;BIND data file for local loopback interface
;
$TTL 86400
@ IN SOA zenon.nossoserver.com. root.nossoserver.com. (
2009041701 ;Serial
43200 ;Refresh
900 ;Retry
2419200 ;Expire
3600) ; Negative Cache TTL
;
@ IN NS zenon.nossoserver.com.
@ IN A 192.168.0.4

Pronto, salve o arquivo, reinicialize o serviço BIND e o sub-domínio estará configurado. Porém, é necessário configurarmos o Apache 2 para que o sub-domínio seja acessível via navegador.

Configurando o Apache 2 para responder pelo domínio

Agora, depois de explicar e detalhar a configuração da zona dns e criarmos nosso domínio e sub-domínio, vamos fazer com que eles sejam acessíveis via navegador, sendo assim, será possível acessá-los digitando no navegador: http://www.nossoserver.com e http://guarani.campeaobrasileiro.com.br.

Supondo que você tenha o Apache 2 instalado e configurado. Vamos acessar o servidor careca.nossoserver.com e editar o arquivo /etc/apache2/sites-available/default inserindo as informações do domínio e do sub-domínio.

# vi /etc/apache2/sites-available/default

Insira as linhas abaixo:

<VirtualHost *:80>
ServerName www.nossoserver.com
DocumentRoot /var/www/www.nossoserver.com
</VirtualHost>
<VirtualHost *:80>
ServerName guarani.campeaobrasileiro.com.br
DocumentRoot /var/www/guarani.campeaobrasileiro.com.br
</VirtualHost>

Entendendo as linhas inseridas:

  • VirtualHost – deixei para que qualquer entrada na porta 80 seja entendido pela configuração;
  • ServerName – o nome do servidor, um pouco óbvio, porém é o endereço do domínio ou sub-domínio que será digitado no navegador;
  • DocumentRoot – caminho onde estão localizados os arquivos que deverão ser exibidos no site, por exemplo, arquivos html, php, png, etc.

Vale lembrar que é necessário existir os diretórios configurados na tag DocumentRoot. E para que você possa ter um resultado mais consistente, eu sugiro que seja criada uma página chamada index.html dentro de cada um dos diretórios.

Agora basta reinicializar o serviço Apache 2 e testar em seu navegador.

# /etc/init.d/apache2 force-reload

Introdução a API de mapas do Google Maps

div class=”single-entry”>

Como sabemos o Google Maps é um excelente serviço, embora ele nos permite inserir um mapa através de um iframe, o real potencial está na sua API de javascript que permite marcar pontos no mapa, pegar coordenadas, traçar rotas, transformar endereços em coordenadas de latitude e longitude.

Vamos então começar inserindo um mapa em nossa página utilizando a API e para isso precisamos inserir a biblioteca do Google Maps:

<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=true"></script>

Agora vamos criar uma função que será chamada no onload da tag body para o mapa somente ser criado após o documento ser totalmente carregado, isso garante que o elemento div no qual iremos inserir o mapa, já esteja carregado quando o código javascript for carregado:

var map = null; 
function carregar(){
	var latlng = new google.maps.LatLng(-29.767954,-57.071657);
			
	var myOptions = {
      		zoom: 12,
      		center: latlng,
      		mapTypeId: google.maps.MapTypeId.ROADMAP
     	 };
		
	//criando o mapa
   map = new google.maps.Map( document.getElementById("mapa") , myOptions );
}

Ver mapa

O código até é bem simples, na linha 3 criamos um objeto que representa uma coordenada em latitude e longitude, esses objetos são utilizados em vários métodos da API.

Na linha 5 definimos as opções iniciais do mapa, na linha 6 definimos o nível de zoom inicial, na linha 7 configuramos onde o mapa será centralizado(utilizamos o objeto criado na linha 3) . Na linha 8 definimos tipo de mapa, podemos utilizar os seguintes: ROADMAP, SATELLITE, HYBRID.

Na linha 12 é onde criamos realmente o mapa. No construtor do objeto o primeiro parâmetro recebe o elemento irá conter o mapa, no segundo os parâmetros de inicialização do mapa que definimos anteriormente. Note que ele armazenamos a referência ao mapa na variável map e é através dela que podemos modificar o mapa inserindo marcadores, etc.

Podemos mudar várias propriedades do mapa através de funções.

//centralizando o mapa
map.setCenter( new google.maps.LatLng(-29.767954,-53.071657) );
//mudando o zoom do mapa
map.setZoom(5);
//mudando o tipo do mapa
map.setMapTypeId(google.maps.MapTypeId.SATELLITE); 

Marcadores

Também podemos inserir um marcador em um determinado ponto do mapa através de marcadores.

var praca = new google.maps.LatLng(-29.756200185902156, -57.08757859271242);
marcadorPraca = new google.maps.Marker({
	position: praca,
   map: map,
   title:"Praça da Cidade"
});

Criamos um marcador simples, basicamente definimos um ponto na linha 1, na linha 2 criamos o objeto de marcador passando as seguintes opções:

position: o ponto do mapa que o marcador vai ser inserido
map: mapa no qual vai ser inserido o marcador
title: um título para o marcador.

Podemos também inserir um ícone personalizado para o marcador através da opção icon

 icon: '/caminho/para/a/imagem'

Veja o exemplo

Eventos de click

Podemos definir certas ações para quando o usuário clicar em um mapa, ou em um marcador, para isso podemos dever criar um listener.

google.maps.event.addListener(map, 'click', function(event) {
	alert(event.latLng)
});

Veja o exemplo

No código acima estamos definindo que “escutaremos” eventos no objeto map ou seja no nosso mapa, e que o evento que escutaremos serão os eventos de “click”(podemos também escutar os eventos de ‘dblclick’, ‘mouseup’, ‘mousedown’, ‘mouseover’, ‘mouseout’) e ao ser executado pelo usuário um desses eventos será executado a function definida que receberá um objeto de evento como parâmetro que irá conter basicamente apenas um atributo, as coordenadas de latitude e logitude de onde foi executado o evento, com isso podemos colocar um marcador no local ou centralizar o mapa por exemplo.

Outra coisa interessante para fazer com evento é fazer abrir um balão com informações ao se clicar em um determinado marcador:

var praca = new google.maps.LatLng(-29.756200185902156, -57.08757859271242);
marcadorPraca = new google.maps.Marker({
      	position: praca,
      	map: map,
      	title:"Praça da Cidade",
});
var infowindow = new google.maps.InfoWindow({
      	content: "aqui voce pode adicionar conteudo <strong>HTML</strong>"
});
  			
google.maps.event.addListener(marcadorPraca, 'click', function(event) {
	infowindow.open(map,marcadorPraca);
});

Veja o exemplo

Primeiro criamos um objeto de janela de informação com o texto do balão.

Depois em vez de “escutarmos” um evento de ‘click’ no mapa inteiro, vamos “escutar” apenas no marcador que criamos e na função que irá executar quando ‘click’ ocorrer irá abrir a janela de informação através do método open que receberá como parâmetro o mapa e ao qual marcador a janela pertence.

Transformar endereço em coordenadas

Como vimos acima, sempre que iremos inserir alguma coisa no mapa deveremos fornecer as coordenadas de latitude e longitude, mas vamos ser sinceros não é algo muito natural, para isso a API do Maps nos fornece um serviço de Geocoding para converter um endereço textual como estamos acostumado em coordenadas.

var endereco = 'Porto Alegre - RS';
geocoder = new google.maps.Geocoder();		
geocoder.geocode({'address':endereco}, function(results, status){ 
	if( status = google.maps.GeocoderStatus.OK){
		latlng = results[0].geometry.location;
		markerInicio = new google.maps.Marker({position: latlng,map: map});		
		map.setCenter(latlng); 
	}			
});

Veja o exemplo

Na linha 1 pegamos o endereço que pode vir de um formulário por exemplo.

Na linha 2 é criado um objeto Geocoder que é responsável por fazer a requisição assíncrona de endereço ao webservice do Maps.

Na linha 3 é feita requisição através do método geocode passando um objeto JSON como requisição, onde definimos que queremos a localização através do endereço ‘address’, também poderíamos enviar uma coordenada para pegar o endereço passando como requisição ‘latLng’.

Após a requisição ser feita será chamada a function que foi passada como segundo parãmentro do método geocode, esta function que recebe como parâmetro um array de resultados gerados pelo service do maps e um código de status da requisição.

Na linha 4 testamos se não houve erros na requisição, e na linha 5 pegamos o primeiro resultado do array e pegamos os dados de geometry.location que contem as coordenadas de latitude e longitude.

Depois apenas colocado um marcador no local do endereço e centralizamos neste local.

Bom isso é o básico, a API do Google Maps permite fazer bem mais coisas e possui muitas outras opções, essas foram apenas as mais básica, então consulte a documentação que é bem completa e com muitos exemplos.