Ir para a pagina do correto utilizador

[barezi]

Olá a todos.

Eu estou a fazer um site e agora chegou-me um problema, é a primeira vez que estou a construir um site e não sei como realmente funciona esta parte.

Entao é o seguinte, imaginem num browser vao á barra das URL e escrevem www.facebook.com/nome de um utilizador e é gerado essa pagina caso exista, então a minha duvida é mesmo essa, como eu posso ir para a pagina de um utilizador?o meu objetivo é escrever um nome numa textbox do meu site e ele ir para a pagina desse utilizador caso ele exista ou mesmo escrever a URL e ele ir tambem caso exista.

Conheço os processos de mostrar os dados do user certo, o html,css e isso, preciso mesmo é de compreender esta parte de chegar a uma pagina de um utilizador que tenho na base de dados, isto claro com a maior segurança e performance possivel, se quiserem indicar tutoriais, artigos ou algo do genero, será sempre bem vindo, eu pesquisei mas n encontrei grande coisa para o meu problema e mts nem tem todo o conteudo que preciso saber.

Obrigado

[HappyHippyHippo]

http://corz.org/serv/tricks/htaccess2.php

[barezi]

Obrigado pelo link,

[barezi]

Uma ultima questão acerca das URLs, estou na pagina eu.php e a minha url é NomeDoMeuSite/eu.php?id=614 depois dentro da pagina eu tenho uma textarea que me permite publicar texto, isso é feito com jquery->ajax->php5 entao é o seguinte eu na pagina eu.php consigo facilmente "apanhar" o valor da variavel id lá na url, mas agora eu preciso do valor dessa variavel no ficheiro onde está o código php5,é muito importante que utilizadores com mais conheçimentos em javascript nao consigam mudar o valor dessa variavel, pois eu poderia fazer o seguinte, no eu.php meter uma variavel que ficava com o id na url depois passar esse valor para javascript e por fim manda-lo pelo ajax para o php5, simples facil e funciona, mas é mt facilmente alteravel esse valor, o problema é que esse valor nao pode ser alterado de maneira alguma pk preciso do valor certo para colocar na database, o ideal seria com a varaivel no ficheiro eu.php arranjar maneira de ser lida apenas pelo ficheiro php5 esse ficheiro php5 é acedido apenas por via ajax do tipo json usando jquery.Algumas ideias de como posso fazer isto?excluindo cookies e sessions pois imaginem mts utilizadores no site seria mts sessions e nao me agrada mt. Se alguem tiver uma ideia ou saiba como posso resolver este problema seria optimo uma ajudinha pois estou mesmo encalhado com isto.

Obrigado

Edited August 1, 2012 at 12:44 AM by barezi

[pmg]

Arranja um hash que contenha esse id.

Manda esse hash para a pagina (por exemplo um campo de input "hidden" ou numa variavel Javascript) e, quando mandares os dados para o servidor manda tambem o hash.

Se houver incompatibilidades, muito provavelmente foi porque alguem andou a brincar no URL

define('SALTVALUE', '123abc!@#$%^&*()ZYX987');
$idhash = md5($id . SALTVALUE);

E noutra parte do codigo (noutra pagina talvez) verifica se esta correcto

if (md5($_GET['id'] . SALTVALUE) != $_GET['idhash']) /* acaros!! */;

[barezi]

pois tb tinha pensado nisso, mas a lógica será assim... no ficheiro eu.php apanho o ID da URL, guardo esse valor numa variavel depois noutra variavel faço o hash desse ID, passo esses dois valores para jquery os quais mando depois pelo ajax para o php5, a minha cena é que na parte de passar os dois valores para o jquery dará para ver o id original e o seu hash, de outra maneira nao consigo fazer chegar os dois valores ao php5, era esta a tua logica tambem?estará correto e seguro fazer isto?

Obrigado pela ajuda

[pmg]

Sim, é essa a ideia.

Para evitar que os acaros alterem o id e o hash é que usas o SALT (pode ser tão complicado quanto quiseres).

O acaro pode ver o id e o hash, mas como não sabe o SALT não consegue fazer um novo hash com outro id.

Para maior segurança, usa um SALT aleatório que muda em cada acesso à página: nesta situação tens que guardar o SALT algures no servidor (base de dados, variável de sessão, ficheiro local, ...)

[HappyHippyHippo]

parece que estás a complicar a situação toda

só existe dois casos no que toca a gravar na base de dados

- criar um registo

- atualizar um registo

se estás a criar um registo, não deverá existir nenhum problema com o ID por que não estás a mexer em dados que não são teus.

se o caso for de atualizar o registo, então deverás verificar se estás a mexer em dados que não tens permissão.

este tipo de verificação deverá sempre envolver informação na base de dados. muito simplesmente, como disseste, é fácil alterar o id do registo pedido a ser alterado.

o que deverás implementar será algo que relacione o registo ao utilizador autenticado. muito provavelmente um campo do registo com o id do dono da informação que poderá ser comparada com o ID de sessão do utilizador autenticado.

claro que o que disse é um sistema muito simplista de permissões de alterações de um registo, mas é mais do que suficiente para o caso apresentado.

como vês, não te preocupes com codificações maradas, deixa eles tentarem alterar o ID que este será verificado do lado do servidor, e se for caso inválido manda o utilizador dar uma volta

[barezi]

mas repara o id que tenho lá em cima na pagina nao dará para relacionar com o id da sessao do user logado ou algo do genero, o id na url será o profile de um user que tenho na base de dados, agr imagina eu tenho a minha sessao iniciada e sou o id 1 e agora vou ao profile de um amigo que é o id 5, e posto lá um comentário eu preciso do id do user target, neste caso o id do meu amigo preciso que seja apenas o id 5 pois esse valor será guardado e depois se alguem com conhecimentos muda o id por exemplo para 10 o target na base de dados ficara como 10 e o comentario que postei nao ira para o sitio certo, ira para o user com o id 10 caso tenha permissoes para postar lá. penso que neste caso seja mesmo boa ideia arranjar um bom sistema de hash para trabalhar com ids, pois preciso para varios targets tanto users como outras coisas.

Mas gostava de debater este assunto e saber outras opinioes de pessoal tb experiente nestas coisas como voçes para tentarmos chegar á melhor soluçao, obrigado pelos comentarios

Edited August 1, 2012 at 12:17 PM by barezi

[HappyHippyHippo]

a questão continua a ser a mesma e a solução volta a cair na no post que fiz

então se só podes fazer posts para teus amigos, só podes adicionar um comentário a um "target" se existe um registo que relacione "tu" (utilizador autenticado) com o "target"

o que quero dizer é, do lado do servidor depois de receber o pedido:

- verifica se existe informação de autenticação

- verificas se existe uma relação entre o utilizador autenticado e o utilizador a que estás a fazer o comentário (target)

- se sim

- porreiro, cria o registo

- se não

- mensagem de erro

como vês, a verificação volta a ser toda do lado do servidor sem necessidade de efetuar maroscas com ID's e hashes no pedido

[barezi]

ya percebi a logica e seria correto, nessa forma seria quase correto mas há um problema imagina que eu estou a postar num amigo meu com o id 5 mas tb tenho um amigo com o id 10 é facil mudar o javascript e meter o id 10 ou seja mais uma vez o target tava mal, apesar de ter o id 10 como uma relaçao com o meu id, mas estava errado na mesma. penso que nao daria certo, e alias eu nao posso apenas postar em amigos meus, poderei postar em quem nao é amigo tb

[HappyHippyHippo]

já que então dá para fazer esse tipo de post só te digo uma coisa : esquece o que estás a tentar fazer para validação porque não faz sentido.

então se posso fazer posts para qualquer pessoa, como podes querer bloquear essa mesma ação ?

vê bem que qualquer tipo de uso de hash pode ser facilmente ultrapassada ao enviar um único post para essa pessoa, depois é só voltar a usar esse hash

por outro lado não faz sentido fazer este tipo de validação porque não podes deduzir nada de um post para criar um comentário.

se tu próprio disseste que podes fazer posts para qualquer pessoa, não podes bloquear um post só porque "achas" que o post era para outro ID, isso não faz sentido.

mesmo que utilizasses método do lado do servidor para "abrir uma possibilidade" de criar um post através de registos, do gênero: "ao pedir para criar um post, é guardado do lado do servidor (de alguma forma) o ID a ser efetuado o post" isso impossibilita algo muito normal na net que é ter URL's gravados para acesso direto a scripts dos sites, isto porque não terias um ID do lado do servidor a dizer qual o "target" a que o post se refere.

conclusão : se o utilizador tem a possibilidade de fazer algo (porque a plataforma assim foi planeada) não podes forçar a que o utilizador não o faça.

no teu caso, se o utilizador pode fazer posts para pessoa X, não podes dizer que o post não é para essa pessoa X.

ok, esta é a minha ideia do teu problema.

mas se mesmo assim pretendes de alguma forma fazer um tipo de validação, será como te disse anteriormente, o utilizado ao efetuar o pedido para criar um post, será guardado no servidor o ID para o "target" pedido (seja por sessão ou na camada de persistência) e depois o post recebido será atuado sobre o ID guardado.

isto porque volto a dizer, é impossível de garantir a veracidade através de hashes pelo simples facto de duplicação das hashes conhecidas.

[barezi]

bom o problema é mais do tipo, eu posso postar em varias pessoas podendo elas estarem na minha lista de amigos ou nao, mas atençao agr nesta parte, eu posso nao conseguir postar em todas as pessoas, pois elas podem meter privacidade nos seus perfis só para os amigos e se eu nao for amigo nao consigo fazer nada, eu sei que com esta parte das privacidades de cada pagina já conseguia filtrar pela parte do servidor pois só permitia postar la se tivesse permissoes para isso, a minha duvida é, eu posso postar em qualquer sitio desde que tenha permissao para isso, agora eu quero postar no target do user certo, pois eu vou conseguir postar em pessoas que nao tenho na minha lista de amigos ou seja nao consigo fazer verificação nenhuma fazendo uma relacao dos ids que tenho na minha lista de amigos. contudo se a base de dados guardar o id do user target errado e que por acaso até tenho permissao para isso, essa mensagem irá parar no sitio errado.Talvez isto seja "problema do user que anda a mudar o javascript" pois nao consigo dizer que ele está a postar no sitio errado...certo?

Só um aparte, para nao ter hash repetidos e ser facil de apanhar, fazia-se uma relaçao do ID com o tempo contado até aos segundos e resolvia-se o problema..penso eu xD

Edited August 1, 2012 at 02:23 PM by barezi

[HappyHippyHippo]

Talvez isto seja "problema do user que anda a mudar o javascript" pois nao consigo dizer que ele está a postar no sitio errado...certo?

exatamente, como não podes supor nada sobre o "target" do post podendo somente validar o id pelas permissões da plataforma, é problema do utilizador.

Só um aparte, para nao ter hash repetidos e ser facil de apanhar, fazia-se uma relaçao do ID com o tempo contado até aos segundos e resolvia-se o problema..penso eu xD

seria um solução se houvesse uma solução de validar isso.

olha para estes casos:

- se crias a hash no servidor no momento da criação da resposta de pedido de criação de comentário, quando o utilizador fazer o submit, o tempo já é diferente (sem contar com o tempo de demora de transmissão)

- se crias a hash no momento de envio (criação do lado do cliente), podes apanhar com um utilizador fora da zona do servidor, logo o tempo que chega é diferente (sem contar com o tempo de demora de transmissão)

- se de alguma forma enviar o tempo no momento do submit, para que desta forma se possa efetuar a validação do lado do servidor, estás a dar a chave ao utilizador para saber o ID, isto porque quem se dá ao trabalho para alterar o ID do post não terá problemas em perder tempo para descobrir o método de hash

conclusão : como referi no post anterior, se mandou para o "target" diferente, problema dele porque será validado no servidor se tem permissões para isso ou não

[barezi]

100% correto

Obrigado pelas digas e pelo debate foi importante mesmo 🙂