+ Responder ao Tópico



  1. #1

    Padrão SOCORRO ---- Alguém sabe a lista de variáveis da versão 2.9.27 ?

    Caros amigos , sou programador web e recebi a tarefa de preparar algumas páginas para um provedor de Internet que utiliza osoftware mikrokit 2.9.27 .

    Gostaria somente de obter uma lista de variáveis disponíveis para acessar informações internas, a exemplo :

    $(username)...$(ip).....

    Minha maior necessidade seriam o Profile e o email do cliente, para que possa exibi-los na pagina de status.

    Grato pela atenção dispensada , me ponho ao dispor para auxiliá-los quando possível.
    Última edição por orionxe; 30-06-2008 às 05:04.

  2. #2

    Padrão

    tá aí um negócio que eu também queria descobir..

    abraços



  3. #3
    Moderador Avatar de Magal
    Ingresso
    Mar 2007
    Localização
    Rio de Janeiro
    Posts
    2.043
    Posts de Blog
    118

    Padrão

    É fechado, muita gente gostaria de saber.

  4. #4

    Padrão

    Existe um ponto de partida que seria a pagina de login gerada pelo hotspot do proprio mk. Nele vc consegue ver o fluxo de negócio pelo menos do login, agora existem maneiras de burlar essa situação.

    Por exemplo.

    Se vc quiser saber quem está navegando no momento, vc conecta via socket, não sei que tipo de linguagem vc vai utilizar, mas no caso do JAVA seria esse o tipo...
    voltando: vc conecta via socket dispara uma consulta e o mesmo lhe retorna os usuários no seu programa vc filtra o que lhe interessa e processa. Fica parecendo um acesso a banco, mas vc deverá adaptar o seu código para utilizar o padrão de string que o MK retorna



  5. #5

    Padrão

    Citação Postado originalmente por efren Ver Post
    Existe um ponto de partida que seria a pagina de login gerada pelo hotspot do proprio mk. Nele vc consegue ver o fluxo de negócio pelo menos do login, agora existem maneiras de burlar essa situação.

    Por exemplo.

    Se vc quiser saber quem está navegando no momento, vc conecta via socket, não sei que tipo de linguagem vc vai utilizar, mas no caso do JAVA seria esse o tipo...
    voltando: vc conecta via socket dispara uma consulta e o mesmo lhe retorna os usuários no seu programa vc filtra o que lhe interessa e processa. Fica parecendo um acesso a banco, mas vc deverá adaptar o seu código para utilizar o padrão de string que o MK retorna

    é mas em determinadas situações, só se conhecemos as váriaveis mesmo, por exemplo, queria colocar o mac através de escrip para todos aqueles clientes que não estão com mac no hotspot, alguma coisa do tipo se tem mac deixe como está se não tem coloque, no entanto não sei qual a váriavel me informaria o usuario que acabou de logar no evento onlogin configurável em "user profile"

  6. #6

    Padrão

    Ai fica mais fácial ainda...

    Veja só...

    Toda consulta ao MK resulta em uma string enorme e com padrão, então vc realiza a consulta aos usuários cadastrados na interface wireless, depois faz a consulta em quem está cadastrado no seu hotspot. feito isso vc cria um objeto para cada resposta. Neste objeto ´vc faz apenas um "De-Para" e aqueles que não estão acadastrados vc cadastra...

    Cara eu to fazendo um programa para controle total do MK, meu sistema irá contemplar pagamento e corte automatico para aqueles que são inadimplentes e desbloqueio quando o cara pagar...
    Mas para isso eu tive que montar os padroes de resposta do MK e estou conseguindo fazer tudo... É só ter um pouco de criativiadade que sai...

    Se tiver alguma dúvida mais específica posta ai, pq um problema seu pode ser o meu algum dia e vice-versa...

    Flw!!!



  7. #7

    Padrão

    Citação Postado originalmente por efren Ver Post
    Ai fica mais fácial ainda...

    Veja só...

    Toda consulta ao MK resulta em uma string enorme e com padrão, então vc realiza a consulta aos usuários cadastrados na interface wireless, depois faz a consulta em quem está cadastrado no seu hotspot. feito isso vc cria um objeto para cada resposta. Neste objeto ´vc faz apenas um "De-Para" e aqueles que não estão acadastrados vc cadastra...

    Cara eu to fazendo um programa para controle total do MK, meu sistema irá contemplar pagamento e corte automatico para aqueles que são inadimplentes e desbloqueio quando o cara pagar...
    Mas para isso eu tive que montar os padroes de resposta do MK e estou conseguindo fazer tudo... É só ter um pouco de criativiadade que sai...

    Se tiver alguma dúvida mais específica posta ai, pq um problema seu pode ser o meu algum dia e vice-versa...

    Flw!!!
    Boa sorte,

    to achando sua saida muito complicada.

  8. #8

    Padrão

    Axo q entendi mais ou menos oq vc ta precisando ....

    Tbem faço o meu sistema de clientes em ASP (hospedado na net) comunicar com o MK pra guardar algumas infos dos clientes no bd em acess ou mysql...

    $(username) 'login do cliente
    $(link-logout) 'link q foiconfigurado qdo o cliente fazo logout
    $(link-redirect) 'link q o cliente tentou entrar e foi bloqueado pelo hotspot
    $(link-advert) 'link d advertencia configurado no hotspot
    $(link-orig) 'link q o cliente tava qdo foi bloqueado pelo "advert do hotspot"
    $(link-login) 'link do login
    $(error) 'erro ocorreu o login
    $(link-login-only) 'link do login no caso (login.html)
    $(bytes-in-nice) / $(bytes-out-nice) 'qtde da trafego feito por vc até o momento
    $(uptime) 'tempo on-line
    $(elif refresh-timeout) 'tempo de refresh q ta configurado no mk o status.htm.
    $(refresh-timeout) 'ultima vez q fez refresh
    $(mac) 'mac do cliente
    $(ip) 'ip do cliente
    $(identity) 'nome do servidor conectado
    $(hostname) 'ip do servidor

    Se souber de mais alguma POSTA awe por favor, porque parece q qto mais descubro essas 'variaveis' eu arrumo algo pra trata-las...



  9. #9

    Padrão Agradeço a todos

    Agradeço a todos os amigos, e posto o resultado positivo que obtive em minha busca incessante pelo saber:

    Variables
    All of the Servlet HTML pages use variables to show user specific values. Variable names appear only in the HTML source of the servlet pages - they are automatically replaced with the respective values by the HotSpot Servlet. For each variable there is an example of its possible value included in brackets. All the described variables are valid in all servlet pages, but some of them just might be empty at the time they are accesses (for example, there is no uptime before a user has logged in).
    • Common server variables:
      • hostname - DNS name or IP address (if DNS name is not given) of the HotSpot Servlet ("hotspot.example.net")
      • identity - RouterOS identity name ("MikroTik")
      • login-by - authentication method used by user
      • plain-passwd - a "yes/no" representation of whether HTTP-PAP login method is allowed ("no")
      • server-address - HotSpot server address ("10.5.50.1:80")
      • server-name - name of hotspot server
      • ssl-login - a "yes/no" representation of whether HTTPS method was used to access that servlet page ("no")
      • server-name - HotSpot server name (set in the /ip hotspot menu, as the name property)
      • interface-name - physical HotSpot interface name (in case of bridged interfaces, this will return the actual bridge port name)
    • Links:
      • link-login - link to login page including original URL requested ("http://10.5.50.1/login?dst=http://www.example.com/")
      • link-login-plain - link to login page, not including original URL requested ("http://10.5.50.1/login")
      • link-logout - link to logout page ("http://10.5.50.1/logout")
      • link-status - link to status page ("http://10.5.50.1/status")
      • link-orig - original URL requested ("http://www.example.com/")
    • General client information
      • domain - domain name of the user ("mt.lv")
      • interface-name - name of the physical interface, on which client is connected (in case of bridge, it will contain the name of bridge port)
      • ip - IP address of the client ("10.5.50.2")
      • logged-in - "yes" if the user is logged in, otherwise - "no" ("yes")
      • mac - MAC address of the user ("01:23:45:67:89:AB")
      • trial - a "yes/no" representation of whether the user has access to trial time. If users trial time has expired, the value is "no"
      • username - the name of the user ("John")
    • User status information:
      • idle-timeout - idle timeout ("20m" or "" if none)
      • idle-timeout-secs - idle timeout in seconds ("88" or "0" if there is such timeout)
      • limit-bytes-in - byte limit for send ("1000000" or "---" if there is no limit)
      • limit-bytes-out - byte limit for receive ("1000000" or "---" if there is no limit)
      • refresh-timeout - status page refresh timeout ("1m30s" or "" if none)
      • refresh-timeout-secs - status page refresh timeout in seconds ("90s" or "0" if none)
      • session-timeout - session time left for the user ("5h" or "" if none)
      • session-timeout-secs - session time left for the user, in seconds ("3475" or "0" if there is such timeout)
      • session-time-left - session time left for the user ("5h" or "" if none)
      • session-time-left-secs - session time left for the user, in seconds ("3475" or "0" if there is such timeout)
      • uptime - current session uptime ("10h2m33s")
      • uptime-secs - current session uptime in seconds ("125")
    • Traffic counters, which are available only in status page:
      • bytes-in - number of bytes received from the user ("15423")
      • bytes-in-nice - user-friendly form of number of bytes received from the user ("15423")
      • bytes-out - number of bytes sent to the user ("11352")
      • bytes-out-nice - user-friendly form of number of bytes sent to the user ("11352")
      • packets-in - number of packets received from the user ("251")
      • packets-out - number of packets sent to the user ("211")
      • remain-bytes-in - remaining bytes until limit-bytes-in will be reached ("337465" or "---" if there is no limit)
      • remain-bytes-out - remaining bytes until limit-bytes-out will be reached ("124455" or "---" if there is no limit)
    • Miscellaneous variables
      • session-id - value of 'session-id' parameter in the last request
      • var - value of 'var' parameter in the last request
      • error - error message, if something failed ("invalid username or password")
      • error-orig - original error message (without translations retrieved from errors.txt), if something failed ("invalid username or password")
      • chap-id - value of chap ID ("\371")
      • chap-challenge - value of chap challenge ("\357\015\330\013\021\234\145\245\303\253\142\246\133\175\375\316")
      • popup - whether to pop-up checkbox ("true" or "false")
      • advert-pending - whether an advertisement is pending to be displayed ("yes" or "no")
    • RADIUS-related variables
      • radius<id> - show the attribute identified with <id> in text string form (in case RADIUS authentication was used; "" otherwise)
      • radius<id>u - show the attribute identified with <id> in unsigned form (in case RADIUS authentication was used; "0" otherwise)
      • radius<id>-<vnd-id> - show the attribute identified with <id> and vendor ID <vnd-id> in text string form (in case RADIUS authentication was used; "" otherwise)
      • radius<id>-<vnd-id>u - show the attribute identified with <id> and vendor ID <vnd-id> in unsigned form (in case RADIUS authentication was used; "0" otherwise)
    Este material foi retirado do seguinte link: HotSpot Gateway - MikroTik Wireless Router, Shop, Certified Consultants and Training

    Todos os créditos ao autor.

  10. #10

    Padrão

    Citação Postado originalmente por orionxe Ver Post
    Agradeço a todos os amigos, e posto o resultado positivo que obtive em minha busca incessante pelo saber:

    Variables
    All of the Servlet HTML pages use variables to show user specific values. Variable names appear only in the HTML source of the servlet pages - they are automatically replaced with the respective values by the HotSpot Servlet. For each variable there is an example of its possible value included in brackets. All the described variables are valid in all servlet pages, but some of them just might be empty at the time they are accesses (for example, there is no uptime before a user has logged in).
    • Common server variables:
      • hostname - DNS name or IP address (if DNS name is not given) of the HotSpot Servlet ("hotspot.example.net")
      • identity - RouterOS identity name ("MikroTik")
      • login-by - authentication method used by user
      • plain-passwd - a "yes/no" representation of whether HTTP-PAP login method is allowed ("no")
      • server-address - HotSpot server address ("10.5.50.1:80")
      • server-name - name of hotspot server
      • ssl-login - a "yes/no" representation of whether HTTPS method was used to access that servlet page ("no")
      • server-name - HotSpot server name (set in the /ip hotspot menu, as the name property)
      • interface-name - physical HotSpot interface name (in case of bridged interfaces, this will return the actual bridge port name)

    • Links:
      • link-login - link to login page including original URL requested ("http://10.5.50.1/login?dst=http://www.example.com/")
      • link-login-plain - link to login page, not including original URL requested ("http://10.5.50.1/login")
      • link-logout - link to logout page ("http://10.5.50.1/logout")
      • link-status - link to status page ("http://10.5.50.1/status")
      • link-orig - original URL requested ("http://www.example.com/")

    • General client information
      • domain - domain name of the user ("mt.lv")
      • interface-name - name of the physical interface, on which client is connected (in case of bridge, it will contain the name of bridge port)
      • ip - IP address of the client ("10.5.50.2")
      • logged-in - "yes" if the user is logged in, otherwise - "no" ("yes")
      • mac - MAC address of the user ("01:23:45:67:89:AB")
      • trial - a "yes/no" representation of whether the user has access to trial time. If users trial time has expired, the value is "no"
      • username - the name of the user ("John")

    • User status information:
      • idle-timeout - idle timeout ("20m" or "" if none)
      • idle-timeout-secs - idle timeout in seconds ("88" or "0" if there is such timeout)
      • limit-bytes-in - byte limit for send ("1000000" or "---" if there is no limit)
      • limit-bytes-out - byte limit for receive ("1000000" or "---" if there is no limit)
      • refresh-timeout - status page refresh timeout ("1m30s" or "" if none)
      • refresh-timeout-secs - status page refresh timeout in seconds ("90s" or "0" if none)
      • session-timeout - session time left for the user ("5h" or "" if none)
      • session-timeout-secs - session time left for the user, in seconds ("3475" or "0" if there is such timeout)
      • session-time-left - session time left for the user ("5h" or "" if none)
      • session-time-left-secs - session time left for the user, in seconds ("3475" or "0" if there is such timeout)
      • uptime - current session uptime ("10h2m33s")
      • uptime-secs - current session uptime in seconds ("125")

    • Traffic counters, which are available only in status page:
      • bytes-in - number of bytes received from the user ("15423")
      • bytes-in-nice - user-friendly form of number of bytes received from the user ("15423")
      • bytes-out - number of bytes sent to the user ("11352")
      • bytes-out-nice - user-friendly form of number of bytes sent to the user ("11352")
      • packets-in - number of packets received from the user ("251")
      • packets-out - number of packets sent to the user ("211")
      • remain-bytes-in - remaining bytes until limit-bytes-in will be reached ("337465" or "---" if there is no limit)
      • remain-bytes-out - remaining bytes until limit-bytes-out will be reached ("124455" or "---" if there is no limit)

    • Miscellaneous variables
      • session-id - value of 'session-id' parameter in the last request
      • var - value of 'var' parameter in the last request
      • error - error message, if something failed ("invalid username or password")
      • error-orig - original error message (without translations retrieved from errors.txt), if something failed ("invalid username or password")
      • chap-id - value of chap ID ("\371")
      • chap-challenge - value of chap challenge ("\357\015\330\013\021\234\145\245\303\253\142\246\133\175\375\316")
      • popup - whether to pop-up checkbox ("true" or "false")
      • advert-pending - whether an advertisement is pending to be displayed ("yes" or "no")

    • RADIUS-related variables
      • radius<id> - show the attribute identified with <id> in text string form (in case RADIUS authentication was used; "" otherwise)
      • radius<id>u - show the attribute identified with <id> in unsigned form (in case RADIUS authentication was used; "0" otherwise)
      • radius<id>-<vnd-id> - show the attribute identified with <id> and vendor ID <vnd-id> in text string form (in case RADIUS authentication was used; "" otherwise)
      • radius<id>-<vnd-id>u - show the attribute identified with <id> and vendor ID <vnd-id> in unsigned form (in case RADIUS authentication was used; "0" otherwise)


    Este material foi retirado do seguinte link: HotSpot Gateway - MikroTik Wireless Router, Shop, Certified Consultants and Training

    Todos os créditos ao autor.

    Essas são as variáveis do sistema hotspot, excluisivamente, e funcionam na personalização da pagina, observando que a maioria é apenas read, não permitindo montar sistema do tipo central do cliente.



  11. #11

    Padrão

    Mas é o seguinde eu uso esse esquema aki...

    Tipo;

    Eu coloko um frame invisivel pro cliente na página alogin.html e uso um tipo cadastro_log.asp?username=$username&ip=$ip&mac=$mac... dae uso um request.querystring na página do meu servidor asp e pego essas informações e salvo no meu banco de dados e depois trabalho elas como eu quero...

    Da uma olhada pra ver como fica: Cyber Internet - Internet Wireless

    Da pra fazer muita coisa com essas "variaveis"...

    QQ coisa tamo ae !!