小程序 用户反馈_用户反馈如何提高我的应用程序的安全性

小程序 用户反馈

by Ethan Ryan

由伊桑·瑞安(Ethan Ryan)

用户反馈如何提高我的应用程序的安全性 (How user feedback improved my app’s security)

Getting published on freeCodeCamp’s Medium publication was super exciting.

在freeCodeCamp的Medium出版物上发表是非常令人兴奋的。

The week my post was accepted, I was busy with work and headed out of town for the weekend, so I didn’t get a chance to check Medium for a few days. I’d gotten some email notifications, and was excited to catch up on the responses to my piece when I got a chance.

我的帖子被接受的那一周，我正忙于工作，周末要出城去，所以几天没机会检查Medium。 我收到了一些电子邮件通知，很高兴能有机会赶上我对作品的回复。

Nice! That big green circle meant claps! New followers! People reading my words and checking out my story generator app! This was awesome!

真好！ 那个大绿色圆圈意味着鼓掌！ 新的粉丝！ 人们正在阅读我的文字并查看我的故事生成器应用！ 太棒了！

Then I read the messages.

然后，我阅读了消息。

Uh-oh spaghetti-os.

呃，意大利面

No bueno.

没有布宜诺斯艾利斯。

Hmm, makes sense.

嗯，有道理。

Yikes!

kes！

Truth be told, I’d never checked out the Network tab in Chrome’s developer tools ¯\_(ツ)_/¯.

说实话，我从未在Chrome开发人员工具¯\ _(ツ)_ /¯中检出“网络”标签。

I spend tons of time in the console of the browser, reading my logs and warnings and errors, but not much time with the other Developer Tools options.

我花了很多时间在浏览器的控制台上，阅读日志，警告和错误，但是在其他开发人员工具选项上却花了很多时间。

Those comments were super helpful, and made me realize I had work to do.

这些评论非常有帮助，让我意识到我有工作要做。

To summarize thus far:

到目前为止的总结：

• Good news: WordNerds was getting some new users! :)

  好消息： WordNerds吸引了一些新用户！ :)

• Bad news: Bad guys could still see a list of all my users, and their email addresses :/

  坏消息：坏人仍然可以看到我所有用户的列表，以及他们的电子邮件地址：/

All anyone had to do to find all my users’s email addresses was go to wordnerds.co, open the console, click on Networking, and go to: https://word-nerds-api.herokuapp.com/users

找到我所有用户的电子邮件地址，所有需要做的就是转到wordnerds.co，打开控制台，单击Networking，然后转到： https ://word-nerds-api.herokuapp.com/users

They’d see this:

他们会看到以下内容：

Note: My first few users didn’t have email addresses stored in the database because they signed up for WordNerds before I made email addresses required attributes via frontend authentication.

注意：我的前几个用户没有存储在数据库中的电子邮件地址，因为在我通过前端身份验证使电子邮件地址成为必需属性之前，他们注册了WordNerds。

Scrolling through that API endpoint, I also noticed another problem that needed to be fixed:

滚动浏览该API端点，我还注​​意到另一个需要解决的问题：

Oops. My username attribute didn’t have any string length limit. Or if it did, that limit was too damn high. Nobody’s username needs to be that long.

哎呀。 我的用户名属性没有任何字符串长度限制。 否则的话，这个限制太高了。 没有人的用户名需要那么长。

For example:

例如：

Jeez Louise. How would anyone remember to paste in the Navy Seal Copypasta in order to sign into WordNerds?!

耶兹·路易丝。 有谁会记得粘贴在Navy Seal Copypasta中以登录WordNerds？

What a hassle. I didn’t want to give my users a bad user experience, expecting them to remember to copy and paste all that copypasta.

真麻烦 我不想给我的用户带来糟糕的用户体验，希望他们记住要复制并粘贴所有的copypasta。

Username input fields are like children: they crave limits.

用户名输入字段就像孩子一样：他们渴望限制。

So I had some work to do.

所以我要做一些工作。

1. I had to protect my user’s email addresses. Again. I thought I’d fixed that last time, but boy was I wrong.

   我必须保护用户的电子邮件地址。 再来一次 。 我以为上次已经解决了，但是男孩我错了。

2. I had to limit how many characters a username could be.
   我必须限制用户名可以包含多少个字符。

3. As my helpful commenters had pointed out, I should only be retrieving the absolutely necessary data from the backend from each API endpoint. I was returning too much data, which was bad for both security and performance reasons. I had to protect my user data and limit the amount of data being returned for each API call.

   正如我的评论员所指出的那样，我应该只从每个API端点的后端检索绝对必要的数据。 我返回的数据太多，出于安全和性能方面的考虑，这是很糟糕的。 我必须保护我的用户数据， 并限制每个API调用返回的数据量。

Cool cool cool. Work work work. Time to get to work.

酷酷酷。 工作工作工作。 该上班了。

保护用户数据 (Protecting user data)

My first and most pressing issue: making sure I wasn’t logging all my users names and email addresses to my /users API endpoint as JSON.

我的第一个也是最紧迫的问题：确保我没有将所有用户名和电子邮件地址都记录为JSON到我的/ users API端点。

There were multiple ways to fix this, and after some thought I decide upon the most obvious, easiest approach, so obvious and easy I was surprised I didn’t realize it sooner. I had no need at all for an API endpoint for all users. So I could simply delete that API call from the frontend, and the corresponding Rails method on the backend.

有多种方法可以解决此问题，经过深思熟虑后，我决定采用最明显，最简单的方法，如此明显而又简单的方法令我感到惊讶，但我没有很快意识到这一点。 我根本不需要所有用户的API端点。 因此，我可以简单地从前端删除该API调用，并在后端删除相应的Rails方法。

I did like showing the total number of users in my app’s Metadata component, though. It was just a simple number, but I liked watching it slowly grow in size as more people signed up on my site.

不过，我确实想在应用程序的元数据组件中显示用户总数。 这只是一个简单的数字，但是我喜欢看着它随着越来越多的人在我的网站上签名而逐渐增长。

So I decided to keep that number, and eliminate all that user data showing up on the API endpoint.

因此，我决定保留该数字， 并消除API端点上显示的所有用户数据。

I kept the API call exactly the same on the frontend, and on the Ruby on Rails backend, I changed the index method in the UserController from this:

我在前端使API调用完全相同，在Ruby on Rails后端，我从以下方法更改了UserController中的index方法：

def index   users = User.all   render json: usersend

to this:

对此：

def index   users = User.all.size   render json: usersend

Note: I could have used length or count instead of size, but size is the best bet according to this StackOverflow post.

注意：我本可以使用length或count而不是size ，但是根据此StackOverflow post ， size是最好的选择。

Now instead of returning an array full of user objects, containing usernames and email addresses, my backend is instead simply returning a number.

现在，我的后端不是返回包含用户名和电子邮件地址的，充满用户对象的数组，而是简单地返回一个数字。

之前： (BEFORE:)

后： (AFTER:)

Whoa! What an amazing transformation!

哇！ 多么惊人的转变！

After that change to the backend, I had some minor changes to the frontend. Instead of rendering props.users.length in my Metadata component, I could simply render props.users. And I could change that name in the container state from this.state.users to this.state.userCount. Easy updates.

在对后端进行更改之后，我对前端进行了一些小的更改。 代替在我的Metadata组件中渲染props.users.length ，我可以简单地渲染props.users 。 我可以将容器状态中的名称从this.state.users为this.state.userCount 。 轻松更新。

No more user data in my publicly accessible API endpoint!

我的公共可访问API端点中没有更多用户数据！

Well, my usernames and email addresses where still accessibly via the /stories endpoint, so I still had that to fix. But that could be dealt with soon.

好吧，我的用户名和电子邮件地址仍然可以通过/ stories终结点进行访问，因此我仍然可以解决该问题。 但这可能很快就会解决。

限制用户名长度 (Limiting username length)

I didn’t like seeing that a username could be as long as the Navy Seal Copypasta, and although it’s nutso that someone would even try making their name that long, I’m glad they did, because now I could fix that issue!

我不希望看到用户名可以和Navy Seal Copypasta一样长，尽管有人甚至会尝试把自己的名字命名这么长是很不现实的，但我很高兴他们这样做了，因为现在我可以解决这个问题！

Thank you, whoever made your WordNerds username crazy long. I’m looking at you, Lorem Ipsum and Navy Seal Copypasta.

谢谢，让您的WordNerds用户名变得疯狂的人。 我在看着你，洛雷姆·伊普苏姆(Lorem Ipsum)和海军海豹突击队(Copyasta)。

I already had some validations on my frontend to make sure that users logging in or signing up for WordNerds had usernames and passwords that were not empty.

我已经在前端进行了一些验证，以确保登录或注册WordNerds的用户的用户名和密码都不为空。

My SignUpForm is a stateful component that called validate in my render function, as well as in my canBeSubmitted function.

我的SignUpForm是一个有状态组件，在我的渲染函数以及canBeSubmitted函数中调用了validate。

I got that validate function from this freeCodeCamp blog post, probably about a year ago.

我大概在一年前从freeCodeCamp博客文章中获得了validate函数。

My original validate function looked like this:

我最初的验证函数如下所示：

validate(name, password) {   return {      name: name.length === 0, //true if username is empty      password: password.length === 0 //true if password is empty   }}

I decided to refactored this function, making it less succinct, but also more clear, so current and future me will understand it:

我决定重构此功能，使其不那么简洁，但也更加清晰，因此我现在和将来都会理解它：

validateFormInputs(name, password) {   let nameIsInvalid = (name.length === 0) //true if empty   let passwordIsInvalid = (password.length === 0) //true if empty   let errorObject = {      name: nameIsInvalid,      password: passwordIsInvalid   }   return errorObject}

I can hear some of you groaning, “Ugg, you made that succinct function so long and ugly! You added variable names for no reason!”

我能听到你们中有些吟，“哦，您做了这么简洁的功能又长又丑！ 您无缘无故地添加了变量名！”

Sure, I’m adding some lines here, but to me, I can now understand more quickly what is happening in this function.

当然，我在这里添加了几行，但是对我来说，我现在可以更快地了解此函数中发生了什么。

Now I simply add some more conditions to be met. Apart of a valid username not being empty, I’m also validating that it cannot be longer than 15 characters.

现在，我只是添加一些需要满足的条件。 除了有效的用户名不能为空之外，我还验证其长度不能超过15个字符。

I choose the number 15 because that’s what Twitter allows for its usernames, and if it’s good enough for Twitter, it’s good enough for WordNerds.

我选择数字15是因为Twitter允许使用它的用户名 ，如果对Twitter足够好，那么对WordNerds也足够。

With my new condition for usernames, my function looks like this:

在使用用户名的新条件下，我的函数如下所示：

validateFormInputs(name, password) {   let nameIsInvalid = (name.length < 2 || name.length > 15)   let passwordIsInvalid = (password.length === 0)   let errorObject = {      name: nameIsInvalid,      password: passwordIsInvalid   }   return errorObject}

Nice! Now the Navy Seal Copypasta can now longer be used as a username on WordNerds.

真好！ 现在，Navy Seal Copypasta现在可以在WordNerds上用作用户名了。

Sorry copypasta fans! Gotta keep your usernames at or under 15 characters from here on in.

对不起，copypasta粉丝！ 从此开始，您的用户名必须保持在15个字符以内。

I realized it was good practice to not allow spaces in usernames either. “Bob Smith” would be a bad username, as would “ ”. I considered adding a simple regex to my function, when I learned about the input pattern attribute in HTML5. Cool! No need to add anything to my function, I could simply update my JSX form field for the username.

我意识到，禁止在用户名中也使用空格是一种很好的做法。 “ Bob Smith”和“”都是错误的用户名。 当我了解HTML5中的输入模式属性时，我考虑过在函数中添加一个简单的正则表达式。 凉！ 无需在函数中添加任何内容，我只需为用户名更新JSX表单字段即可。

My React frontend’s username form field now looks this:

我的React前端的用户名表单字段现在看起来像这样：

Which results in this alert in the browser:

这会在浏览器中导致此警报：

I made similar updates to my SignUpForm as I did to my LoginForm, and included some validations for email addresses.

我对SignUpForm所做的更新与对LoginForm所做的更新类似，并且包括对电子邮件地址的一些验证。

Sweet, now I just had to make sure there weren’t any email addresses being made visible in my /stories API endpoint. To the backend!

亲爱的，现在我只需要确保在/ stories API端点中没有任何可见的电子邮件地址即可。 到后端！

限制每个API调用返回的数据 (Limiting data returned for each API call)

Blah blah blah, a bunch of stuff on the backend.

等等等等，后端有很多东西。

I didn’t do a good job or writing this stuff down cuz I was trying to get it done quickly, and when that failed, I was trying to get it done.

我做得不好，也没有把这些东西写下来，因为我试图尽快完成它，但是当失败时，我试图完成它。

I’m continuing to think of ways to improve what data is returned from my API endpoints, to make my app both more secure and more scalable.

我一直在思考改善从我的API端点返回的数据的方法，以使我的应用程序更加安全和可扩展。

But to summarize, no more email addresses being made visible in my /stories API endpoint!

但总而言之，在我的/ stories API端点中不再显示任何电子邮件地址！

Now each story has a user_name attribute, in addition to a user_id attribute, but no more email addresses are accessible via the API.

现在，每个故事除了具有user_id属性外，还具有user_name属性，但是无法通过API访问更多电子邮件地址。

The argument could be made that I’m still exposing my app’s users’ usernames, and that I shouldn’t be doing that. But I’m treating those usernames as public info. Users can choose their usernames, so it’s up to them how revealing they want to be in their username choice. It could be RichAt123FakeSt, or it could be batman6669. Who am I to judge what my app’s users choose as their usernames? It’s not like I’m revealing their extremely personal email addresses or anything! I mean, not anymore.

可以说我仍在公开应用程序用户的用户名，我不应该这样做。 但我将这些用户名视为公共信息。 用户可以选择他们的用户名，因此要由他们自己决定要如何显示用户名。 可能是RichAt123FakeSt，也可能是batman6669。 我该如何判断应用程序用户选择的用户名？ 并不是说我要透露他们极其个人化的电子邮件地址或任何东西！ 我的意思是，不再。

结论：反馈很好 (Conclusion: Feedback is good)

After making those security updates, I made a few more fun changes as well. It’s fun to continually be improving my app, thanks to helpful feedback from internet strangers, as well as whatever zany feature I think will make it better.

进行了安全更新之后，我还进行了一些有趣的更改。 不断改进我的应用程序很有趣，这要归功于互联网陌生人的有用反馈，以及我认为会使它变得更好的任何奇怪功能。

Check out WordNerds here, at WordNerds.co.

在WordNerds.co上查看WordNerds 。

Thanks for reading, nerds!

书呆子，感谢您的阅读！

Till next time.

直到下一次。

翻译自: https://www.freecodecamp.org/news/how-user-feedback-improved-my-apps-security-53eb11977880/

小程序 用户反馈