[aur-dev] [PATCH v2] Fake pkgbase actions for unconfirmed users

[Lukas Fleischer]

On Fri, 26 Jun 2015 at 21:03:17, Gordian Edenhofer wrote:
> Displaying flag, notify, vote, adopt and file request links for
> users which did not authenticate themselves and letting those fake
> buttons link to the login page.

Forgot to mention it in your previous patches but could you add your
sign-off, please (simply pass -s when running `git commit`)?

> ---
> Agreed, the statements were kind of redundant.
> I hope this patch is more straightforward.
> 

Looks much better indeed, thanks! Some comments below.

>  web/lib/aur.inc.php              | 33 ++++++++++++++++++++++-----------
>  web/template/pkgbase_actions.php | 26 ++++++++++++--------------
>  2 files changed, 34 insertions(+), 25 deletions(-)
> 
> diff --git a/web/lib/aur.inc.php b/web/lib/aur.inc.php
> index 95f72ce..98ebde4 100644
> --- a/web/lib/aur.inc.php
> +++ b/web/lib/aur.inc.php
> @@ -226,11 +226,16 @@ function html_format_maintainers($maintainer, $comaintainers) {
>   *
>   * @param string $uri The link target
>   * @param string $desc The link label
> + * @param string $uid The User ID
>   *
>   * @return string The generated HTML code for the action link
>   */
> -function html_action_link($uri, $desc) {
> -       $code = '<a href="' . htmlspecialchars($uri, ENT_QUOTES) . '">';
> +function html_action_link($uri, $desc, $uid="") {

Do we really need to make the $uid parameter optional? Do we skip the
parameter somewhere? If it makes sense, could we please use false as
default value instead of an empty string?

> +       if ($uid) {
> +               $code = '<a href="' . htmlspecialchars($uri, ENT_QUOTES) . '">';
> +       } else {
> +               $code = '<a href="' . get_uri('/login/', true) . '">';
> +       }
> [...]

Cool, this is kind of what I expected! I wonder whether we can directly
set a referer here, though? Shouldn't something like

    get_uri('/login/', true) . '?referer=' . urlencode($uri)

work?

Having said that, I now see a potential problem with the GET parameter
approach of implementing FS#32481. You could build a malicious login
link that redirects to a certain page and send that link to a privileged
user (i.e. a TU or a Developer). I am not aware of any action that
cannot be undone and doesn't require any additional confirmation, so
that probably isn't very critical. We should fix it anyway...

Regards,
Lukas