在 Shiny 中使用基本服务器端授权的缺点答案

【问题标题】：Disadvantages of Using Basic Server-Side Authorization in Shiny在 Shiny 中使用基本服务器端授权的缺点
【发布时间】：2018-08-09 12:13:36
【问题描述】：

我在 Shiny 上创建了非常基本和原始的授权。它只是检查服务器端的用户名-密码对，并有条件地显示隐藏界面。

使用这种原始授权有什么缺点？

library(shiny)

ui <- fluidPage(uiOutput("auth"))

server <- function(input, output) {

  output$auth <- renderUI({
    tagList(
      textInput(inputId = "username",label = "Username"),
      passwordInput(inputId  = "userpassword",label = "Password"),
      actionButton("userlogin", "Login")
    )})

  observeEvent(input$userlogin, {
    if(input$username=="demo" & input$userpassword=="demo") {
      output$auth <- renderUI({
        tagList(
          textInput(inputId = "Secret",label = NULL, placeholder = "Secret Data...")
        )})
    }
  })

}

shinyApp(ui = ui, server = server)

【问题讨论】：

标签： r security authentication shiny authorization

【解决方案1】：

我不是安全专业人士，但我想到的潜在问题是隐藏部分的反应性质。我相信您需要在大多数反应式前面加上一个 shiny::validate 语句，以防止对输入对象的操作触发底层操作。

在这种情况下，假设某些东西依赖于 input$Secret 输入，他们可以在他们的客户端页面上创建一个输入，然后将他们想要的任何内容提交给您。

现在假设你有这个部分：

# Insert Secret into database
observeEvent(input$Secret, {
    # INSERT RECORD
})

他们可以触发它，而无需访问您创建的 textInput 部分。

聪明的演员可以随心所欲地制作输入对象，因此您需要在编写应用程序的每个部分时牢记这一点。

这并不是说这是不可能的，但是有很多陷阱，这里有一个方法来处理上面的验证问题

authorized <- eventReactive(input$submitpass, {
    input$username == 'demo' & input$password == 'demo'
})
# Insert Secret into database
observeEvent(input$Secret, {
    shiny::validate(need(authorized(), 'You are not authorized'))
    # INSERT RECORD
})

编辑：

另外值得注意的是，编写授权很难，我很想使用现成的东西，而不是尝试自己酿造。尤其是当您拥有多个用户并存储/散列密码时......这非常不容易

【讨论】：