在单页应用程序中创建临时 URL [英] Creating temp URLs in single page applications

问题描述

在我基于 React 的单页应用程序中，我的页面分为两个窗格.

In my react based single page application, my page is divided in two panes.

左窗格:过滤器面板.

右窗格:网格(包含通过应用过滤器的数据的表格)

Right Pane: Grid (table containing data that passes through applied filters)

总而言之，我有一个与 amazon.com 非常相似的应用程序.默认情况下，当用户在浏览器中点击应用程序的根端点 (/) 时，我会从服务器获取过去 7 天的数据并将其显示在网格中.

In summary, I have an application that looks very similar to amazon.com. By default, when user hits an application's root endpoint (/) in the browser, I fetch last 7 days of data from the server and show it inside the grid.

过滤器面板有几个过滤器(例如，时间过滤器用于获取落在指定时间间隔内的数据，ID 用于搜索具有特定 id 的数据等)和一个附加在过滤器面板标题中的搜索按钮.点击搜索按钮通过在帖子表单正文中提供选定的过滤器来对服务器进行帖子调用，服务器返回与传递的过滤器匹配的数据，我的前端应用程序显示从网格内的服务器返回的数据.

Filter panel has couple of filters (e.g. time filter to fetch data that falls inside specified time interval, Ids to search data with specific id etc.) and a search button attached in the header of filter panel. Hitting search button makes a post call to a server by giving selected filters inside post form body, server returns back data that matches filters passed and my frontend application displays this data returned back from the server inside grid.

现在，当有人点击过滤器面板中的搜索按钮时，我想在 URL 的查询参数中反映选定的过滤器，因为这将帮助我与我网站的其他用户共享这些 URL，以便他们可以看到过滤器我申请并查看了网格内仅与这些过滤器匹配的数据.

Now, when someone hits search button in the filter panel I want to reflect selected filters in the query parameter of the URL, because it will help me to share these URLs with other users of my website, so that they can see filters I applied and see data inside the grid matching these filters only.

这里的问题是，如果在单击搜索按钮时，我使用带有查询参数的 http get，由于不同浏览器对 URL 长度的限制，我最终会破坏应用程序.

Problem here is, if on search button click, I use http get with query parameters, I will endup breaking application because of limit imposed on URL length by different browsers.

请建议我创建此类 URL 的正确解决方案，以帮助我在过滤器面板中设置选定的过滤器，而不会对我的应用程序造成任何副作用.

Please suggest me correct solution to create such URLs that will help me to set the selected filters in the filter panel without causing any side effect in my application.

可能的解决方案: 考虑到由于不同浏览器的 URL 长度限制，我们不能直接在查询参数中添加纯字符串(注:规范不限制 HTTP Get 请求的长度，但不同浏览器实现自己的限制)，我们可以使用诸如消息摘要或哈希之类的东西(将任意长度的输入转换为固定长度的输出)并将其保存在数据库中，以便服务器理解请求并返回内容.这只是一个想法，我不确定这是否是这个问题的理想解决方案.

Possible solution: Considering the fact that we cannot directly add plain strings in query parameter because of URL length limitation from different browsers (Note: Specification does not limit the length of an HTTP Get request but different browsers implement their own limitations), we can use something like message digest or hash (convert input of arbitrary length into an output of fixed length) and save it in DB for server to understand the request and serve content back. This is just a thought, I am not sure whether this is an ideal solution to this problem.

其他频繁使用的网站的行为:

Behavior of other heavily used websites:

• amazon.com、newegg.com -> 使用散列网址.
• kayak.com -> 因为他们有非常明确的关键字，所以他们使用像 IN 代表印度，BLR 代表班加罗尔等的简短形式，并结合这带有否定逻辑以进一步优化最大 url 长度.不是已检查，但理想情况下会在大量选择过滤器后中断.
• flipkart.com -> 将字符串直接附加到查询参数并中断突破限制后.验证了这一点.

• amazon.com, newegg.com -> uses hashed urls.
• kayak.com -> since they have very well defined keywords, they use short forms like IN for INDIA, BLR for Bangalore etc. and combine this with negation logic to further optimize maximum url length. Not checked but this will ideally break after large selection of filters.
• flipkart.com -> appends strings directly to query parameters and breaks after limit is breached. verified this.

推荐答案

针对 @cauchy 的回答，我们需要区分散列和加密.

In response to @cauchy's answer, we need to make a distinction between hashing and encryption.

哈希必然是不可逆的.为了将哈希映射到特定的过滤器组合，您需要

Hashes are by necessity irreversible. In order to map the hash to the specific filter combination, you would either need to

1. 为每个请求对服务器上的每个过滤器排列进行散列，以尝试匹配请求的散列(计算密集型)或
2. 在服务器上存储哈希映射以过滤组合(内存密集型).

对于绝大多数情况，选项 1 会太慢.根据过滤器和选项的数量，选项 B 可能需要相当大的地图，但它仍然是您的最佳选择.

For the vast majority of cases, option 1 is going to be too slow. Depending on the number of filters and options, option B may require a sizable map, but it's still your best option.

在这个方案中，服务器将其公钥发送给客户端，然后客户端可以使用它来加密其过滤器选项.然后服务器将使用其私钥解密加密数据.这很好，但是您的加密数据不会是固定长度的.因此，随着更多选项，您遇到了不确定的参数长度的相同问题.

In this scheme, the server would send its public key to the client, then the client could use that to encrypt its filter options. The server would then decrypt the encrypted data with its private key. This is good, but your encrypted data will not be fixed length. So, as more options are selected, you run into the same problem of indeterminate parameter length.

因此，为了确保您的 URL 对于任意数量的过滤器和选项都是短的，您需要在服务器上维护一个 hash->selection 的映射.

Thus, in order to ensure your URL is short for any number of filters and options, you will need to maintain a mapping of hash->selection on the server.

您在上面的评论中提到

如果我们使用一些持久化存储来保存这个哈希到实际过滤器之间的映射，我们理想情况下希望将长期存在的永久链接"与短期存在的临时 URL 分开，并使用这种理解来有效地使短期存在散列.

If we use some persistent store to save the mapping between this hash to actual filters, we would ideally want to segregate long-lived "permalinks" from short-lived ephemeral URLs, and use that understanding to efficiently expire the short-lived hashes.

您可能在服务器上有一个服务来处理您在应用程序中支持的所有过滤器.这里的技巧是让该服务也管理哈希图.随着更多过滤器和选项的添加/删除，服务将需要重新散列过滤器选择的每个排列.

You likely have a service on the server that handles all of the filters that you support in your application. The trick here is letting that service also manage the hashmap. As more filters and options are added/removed, the service will need to re-hash each permutation of filter selections.

如果您需要对永久链接的强大支持，那么无论何时删除过滤器或选项，您都需要维护过期"哈希并将其映射更改为指向合理的替代哈希.

If you need strong support for permalinks, then whenever you remove filters or options, you'll want to maintain the "expired" hashes and change their mapping to point to a reasonable alternative hash.

有很多选择，但我通常更喜欢构建时间.如果您使用的是 Jenkins、Travis、AWS CodePipeline 等 CI 解决方案，那么您可以添加一个构建步骤来更新您的数据库.基本上，您将...

There are lots of options, but I would generally prefer build time. If you're using a CI solution like Jenkins, Travis, AWS CodePipeline, etc., then you can add a build step to update your DB. Basically, you're going to...

1. 保留所有现有支持的过滤器的持久记录.
2. 在构建时，检查是否有任何新过滤器.如果是这样的话...

1. Keep a persistent record of all the existing supported filters.
2. On build, check to see if there are any new filters. If so...

1. 将这些过滤器添加到第 1 步的记录中.
2. 散列所有新的过滤器排列(仅包含您的新过滤器的排列)并将它们存储在散列数据库中

检查是否删除了任何过滤器.如果是这样的话...

Check to see if any filters have been removed. If so...

1. 从第 1 步的记录中删除这些过滤器.
2. 查找包含这些过滤器的排列的所有散列，或者...
   • 从数据库中删除这些哈希值(弱永久链接)，或
   • 将该哈希指向数据库中合理的替代哈希(强固定链接)

这篇关于在单页应用程序中创建临时 URL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！