Get request with & ampersand for multiple parameters, %html(), %url() and %qp()

(1) By anonymous on 2025-02-12 11:31:17 [link] [source]

Hi,

I haven't yet understood how to write an anchor href using %html(...), %url(...), and %qp(...).

For example, given wapp-trim " <a href='$BASE_URL/get-server-detail?server=$s&env=$tbl'>View</a> "

I can retrieve the two parameters' values by doing:

puts "[wapp-param server]" puts "[wapp-param env]"

Given what is said in the intro, a %url(...), %html(...) or %qp(...) should be used.

Other supported substitutions are "%url(...)" for URLs on the href= and src= attributes of HTML entities, "%qp(...)" for query parameters

But, when using any of the following, the 'server' and 'env' parameters are not read correctly by wapp, because the ampersand is not taken as a separator.

<a href='%url($BASE_URL/get-server-detail?server=$s&env=$tbl)'>View</a> <a href='%html($BASE_URL/get-server-detail?server=$s&env=$tbl)'>View</a> <a href='%url($BASE_URL/get-server-detail)?%qp(server=$s&env=$tbl)'>View</a>

What and how should I use in the query to be able to read multiple parameters?

Another question regarding %html(...) and %url(...): In this example, a %html(...) was used inside a href. <li><a href="%html($base/$file)">%html($file)</a></li> Should it be a %url(...)?

(2.12) By ufko.org on 2025-02-13 06:50:21 edited from 2.11 in reply to 1 [source]

<a href='%url($BASE_URL/get-server-detail?server=$s&env=$tbl)'>View</a>

<a href='%url($BASE_URL)/get-server-detail?server=%qp($s)&env=%qp($tbl)'>View</a>

You substitute only Tcl variables in the URL with url(), and only Tcl variables in the query string with qp(), because what you read in your Wapplication are query string variable's values not the query string variable's names or other hardcoded parts :)

BUT: A simple URL without a query string can be enclosed entirely in url().

wapp-trim {<a href="%url($BASE_URL/get-server-detail)">Details</a>} .. Don’t hesitate to use wapp-trim {} instead of wapp-trim "" and double quotes in href= .. there is nothing to substitute with wapp-trim "" because url() did it already

In other words: You simply sanitize values that an attacker could tamper with, not the parts you’ve hardcoded into the URL, like a path head (/get-server-detail in your case) or a variable name (server and env in your case). If someone tries to mess with /get-server-detail, they'll first run into the same-origin problem even if he guessed the name of some wapp-page-* function, and if not, the second slap will come from wapp-default {}. 😆

I hope I didn’t make a typo. 😄

I don’t feel like dealing with the second case. 😆 Either it’s a typo, but two times is too much, or html() was used because, in this specific case, the variables contain something that url() doesn’t sanitize.

Jesus, by the time I'm satisfied with my answer, I'll flood this place with 20 versions. 😆

(3) By anonymous on 2025-02-14 08:25:31 in reply to 2.12 [link] [source]

Thank you very much for your explanation, ufo.org. All the best!

(4.1) By ufko.org on 2025-02-14 15:33:48 edited from 4.0 in reply to 3 [link] [source]

The best thing is to separate the development and production environment settings right from the start.

if {[info hostname] == "<local-machine-hostname>"} {
  # Local machine
  const url https://ufko.test
  const dbfile /path/to/sqlite3db
  const debug 1
  const log 1
  const local 1
  proc wapp-before-dispatch-hook {} {
    wapp-allow-xorigin-params
  }
} else {
  # Remote machine
  const url https://ufko.org
  const dbfile /path/to/sqlite3db
  const debug 0
  const log 0
  const local 0
  # Turns off error messaging in production
  # Todo: log into logfile :)
  proc wapp-crash-handler {} {
    wapp-trim {Oops ...}
  }
  # Before dispatch settings
  proc wapp-before-dispatch-hook {} {
    # ...
  }
}

Note wapp-allow-xorigin-params ... And then use those %() and %()% subst tools, even in forms when returning values.