这是“邀请好友”吗?我的网站系统对您来说听起来有缺陷吗?

发布于 2024-08-15 10:27:50 字数 491 浏览 7 评论 0原文

我想要一个系统,我的用户可以邀请他们的朋友。我们不喜欢在发送邀请链接时使用 URL 缩短器,但链接相对较短也很重要。我认为实现这一目标的最佳方法就是为每个用户提供一个“个人资料用户名”,例如“tonyamoyal12”,并让他们根据需要请求一个新的唯一用户名。

当我的用户发出邀请时,它会发送一个类似 http://mydomain/invite/profile_username 的 URL 和本质上,如果被邀请者通过该 URL 登录,邀请者就会获得积分。有人能想到这种方法的缺点吗?大多数邀请 URL 都有哈希值来验证邀请的完整性,但我认为我的方法效果很好。

更新 个人资料用户名是邀请者的用户名,而不是受邀者的用户名。因此,用户在邀请者的个人资料页面上注册,因此邀请者会因为有人在他的页面上注册而获得“积分”。

谢谢!

I would like to have a system where my users can invite their friends. We prefer not to use a URL shortener when sending the invite link but it is also important that the link be relatively short. I am thinking the best way to accomplish this is just give each user a "profile username" like "tonyamoyal12" and let them request a new unique one if they want.

When my users send out invites, it will send out a URL like http://mydomain/invite/profile_username and essentially if the invitee logs in at that URL, the inviter gets credit. Can anyone think of drawbacks to this approach? Most invite URL's have hashes to verify the integrity of the invite but I think my approach works fine.

UPDATE
The profile username is that of the INVITER not INVITEE. So a user signs up on the INVITER'S profile page and therefore the inviter gets a "point" for having someone sign up on his page.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

滥情稳全场 2024-08-22 10:27:50

在这些类型的系统中,在被邀请者实际注册之前,您通常不会分配任何用户数据(即用户名),并且根据您所使用的框架,让这种 URL 正常工作可能会有点麻烦。正在使用。

该过程通常是:

  1. 邀请用户,然后向他们发送电子邮件。
  2. 受邀者单击电子邮件中的链接转到网站的主注册页面。
  3. 受邀者使用他们选择的有效用户名进行注册,并基于一些唯一的随机密钥(包含在点击链接中),您可以与涉及的两个用户一起执行业务逻辑(添加到朋友列表或其他)。

生成自己的用户名的缺点是它们比随机数更容易被猜测,因为您可能会在其中使用英文单词。如果您生成并分配随机用户名(即“s243k2ldk8sdl”),被邀请者将不会高兴,因为他们必须做额外的工作来更改用户名,或者以某种方式记住该名称。

编辑,因为我不太明白这个问题。

我认为这个方案很好,除了我只在 URL 中使用邀请者的用户名并且不允许他们更改它(为什么允许它?)。唯一的问题是,如果对邀请数量有某种限制(或者可能每个邀请都有奖励),您希望使用某种仅对邀请者有效的唯一哈希值来保护每次点击网址。

编辑2

由于系统中的用户没有分配用户名,因此您可以采用任何一种方法。允许以先到先得的方式分配“用户名”就可以了,因为这可以让每个人更轻松地与朋友分享他们的 URL,因为它很容易记住并且可以简单地输入。但是,如果注册需要一个唯一的密钥...在这种情况下,不实现用户名并将每个人引导到某种单一注册页面会更简单。

In these types of systems, you don't usually assign any user data (i.e., user names) before the invitee has actually signed up, and it may be a bit of a pain to get that kind of URL working depending on the framework you're using.

The process is normally:

  1. Invite a user, which sends them an e-mail.
  2. Invitee clicks through a link in the e-mail to go to the site's main registration page.
  3. Invitee registers with a valid user name of their choosing, and based on some unique random key (included in the clickthrough link), you can do your business logic with the two users involved (add to friends list, or whatever).

The drawback to generating your own user names is that they're more likely to be guessed than a random number, because you'll likely use English words in them. If you generate and assign random user names (i.e., "s243k2ldk8sdl"), the invitee is not going to be pleased since they have to do extra work to change the user name, or somehow remember that name.

EDIT, since I didn't understand the question very well.

I think the scheme is fine, except I would just use the invitor's user name in the URL and not allow them to change it (why allow it?). The only issue is if there is some kind of limit put on the number of invites (or maybe there is a reward for each invite), where you'd want to secure each clickthrough with some kind of unique hash value only valid for the invitor's URL.

EDIT 2

Since the users in the system do not have user names assigned, you could go either way. Allowing "user name" assignment on a first-come, first-served basis would be fine, as this would let everyone share their URL more easily with friends since it's memorable and can simply be typed in. However, that goes out the window if a unique key is required to sign up... in which case, it's going to be simpler to just not implement the user name thing and direct everyone to a single registration page of some kind.

梦幻的味道 2024-08-22 10:27:50

为什么不创建您自己的定制 URL 缩短呢?

如果您避免 URL 缩短的原因是您不想依赖外部公司,那么这对您来说可能是一个很好的解决方案。

Why not just create your own bespoke URL shortening?

If the reason you are avoiding URL-shortening is that you don't want to depend on external companies then that could be a good solution for you.

南薇 2024-08-22 10:27:50
  1. 您无法独立跟踪邀请。在某些时候,您可能想知道用户发出了多少邀请,以及接受了多少邀请。使用这个单一 URL 系统,您无法跟踪该信息。

  2. 机器人很容易被写入垃圾邮件这样的系统。 (也许可以在结果页面上使用验证码解决)

  1. You can't independently track the invites. At some point you may want to know how many invites went out from a user vs. how many were accepted. With this single URL system you can't track that information.

  2. Bots can easily be written to spam such a system. (Perhaps solved with captcha on resulting pages)

分開簡單 2024-08-22 10:27:50

好吧,如果网站很大,您会遇到名称冲突,并且您将依赖于邀请者输入被邀请者的姓名,而他们可能做得很差。

如果你想这样做,那么你将不得不处理名称冲突的问题。

也有可能有人会过来并决定随机输入名字,看看他们是否会被击中。假设我想八卦并监视一个朋友,看看他们是否向其他朋友发送邀请。

编辑:啊好吧。好吧,如果他们只是单击链接即可转到邀请者,那么这不是问题。这看起来完全正常,并且暴露的用户名没有什么秘密。

well if the website is large you will get name conflicts, and you will be dependent on the inviter putting in the invitees name which they could do poorly.

If you want to do it that way then you will have to deal with name clashes.

Also it is possible that someone could come along and decide to randomly type in names to see if they get it hit. Say I wanted to be nosey and spy on a friend to see if they are sending out invites to other friends.

EDIT: ahh ok. well if they are just clicking a link to go to the inviter then thats not a problem. That seems perfectly normal and there is no secret about exposed usernames.

岁月无声 2024-08-22 10:27:50

您可以为每个邀请创建一个唯一的哈希值,并保持哈希值与用户名的关联。这将需要一些存储开销,但您可能会通过邀请过期来帮助解决这个问题。

因此 http://mydomain/invite/RgetSqtu 将是一个示例链接,其中包含存储 RgetSqtu/ 的数据库表配置文件,直到使用为止。

如果找不到哈希,您可能希望提供一个有用的错误页面,如下所示:

很抱歉,找不到您输入的邀请。这可能是由于邀请输入不正确、已被使用或太旧(邀请在 3 天后过期)造成的。

You could create a unique hash for each invite and keep an association of hashes with user names. This would require a bit of storage overhead, but you could have expiration of invites to help combat that.

So http://mydomain/invite/RgetSqtu would be an example link, with a DB table that stores RgetSqtu/profile until it is used.

You would probably want to provide a helpful error page if the hash could not be found, like the following:

We are sorry but the invite you entered could not be found. This could be caused by the invite being typed incorrectly, being used already, or being too old (invites expire after 3 days).

不即不离 2024-08-22 10:27:50

我建议在查询字符串中传递邀请者的用户名,并让该查询字符串填充新用户注册页面上的可编辑或不可编辑的文本框。这样一来,您仍然只有一个注册页面,URL 很短,并且用户可以通过推荐朋友获得积分。

http://mydomain/invite/register.html?inviter=invitersUsername

导致

名字:_________
姓氏:_________
推荐人:invitersUsername

I'd suggest passing the inviter's username in the querystring, and have that querystring fill either an editable or non-editable textbox on the new user registration page. That way you still have just one registration page, the URL is short, and users get credit for referring friends.

http://mydomain/invite/register.html?inviter=invitersUsername

leads to

First Name: _________
Last Name: _________
Referred By: invitersUsername

长途伴 2024-08-22 10:27:50

如果我正确理解该设置,现有用户会通过向其朋友发送电子邮件来创建邀请,您的系统将向其发送包含 [inviteUrl]/[inveter'sUserName] 的邮件。
因此,如果我发送邮件邀请您,网址将为:

www.yourThang.com/invite/borisCallens

每次有人访问此链接时,我(用户 borisCallens)都会获得积分。
什么会阻止我无数次访问该网址并赢得邀请好友游戏?

If I understand the setting correctly an existing user creates invites by giving emails of their friends to which your system will send a mail with in that the [inviteUrl]/[inveter'sUserName].
So in the case I send a mail to invite you, the url would be:

www.yourThang.com/invite/borisCallens

Every time somebody visits this I (the user borisCallens) gets a point.
What would stop me from visiting this url a gazillion times and thus win the invite-your-friend game?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文