天道酬勤,学无止境

会话刷新后,我还可以访问 sitecore 联系人方面吗?(Can I still access a sitecore contact facet once session is flushed?)

问题

我希望我没有在这里弄错了(一如既往,sitecore 文档很糟糕!)

我想要一种针对访问者存储信息的方法,我对 sitecore 相当陌生,但联系方面似乎是理想的解决方案,几乎从上面的链接逐字执行,直到它投入生产我对它非常满意。 当我存储它持久的信息时,我可以阅读它:

public IMpmVisitorFacet GetMpmVisitorFacet()
{
    return _contact.GetFacet<IMpmVisitorFacet>(_MPMVisitorConfigName);
}

并设置信息,一切似乎都很棒。 我还可以看到设置了 sitecore SC_ANALYTICS_GLOBAL_COOKIE ,一切看起来都很棒。 然后我做了一些更彻底的测试......

问题似乎是数据不会持续很长时间。 如果我在 facet 中放入一些信息,它会停留一个小时左右(我可以关闭我的浏览器,查看其他网站,等等)并且我将能够访问它,但是在“时间”一切都会过去。

重新访问文档后(我有没有提到它们不是很好),我注意到我以前没有看到的一句话中有一个警告:

好吧,我可以创建另一个仅读取员工编号的 Web 表单页面。 这将告诉我联系人方面的数据至少存储在内存中。 但是永久存储呢?

等等,我以为这是永久存储?! 所以这个例子显示了一些读取“facet”的代码。

var contact = Tracker.Current.Contact;
var data = contact.GetFacet<IEmployeeData>("Employee Data");
data.EmployeeId = "ABC123";
.....
<p>Employee data contact facet updated.</p>
<p>Contact ID: <b><%=contact.ContactId.ToString()%></b></p>
<p>Employee #: <b><%=data.EmployeeId%></b></p>

但这方面似乎只存在了很短的一段时间。 然后继续:

出于性能原因,Sitecore 仅在会话结束时将联系人数据写入 xDB。这意味着,如果我查看 MongoDB ...

然后它继续在其新的闪亮时尚 mongoDb 实现中显示数据。 但是,如果我无法以编程方式实际访问和使用该信息,那么它在 mongo 中有什么用!

所以这就提出了一个问题,一旦会话被放弃,我该如何访问这个联系信息?

即用户登录我的网站 -> 我在他们的联系方式中添加了一些信息 -> 他们第二天回来 -> 我想阅读我之前添加的信息

还有其他几个文档讨论了在体验配置文件中访问这些数据、索引到 Lucene 和体验平台(为什么有两个名称几乎完全相同的产品?!)但没有说明如何在网站本身,在代码中。


添加到 Dmytro Shevchenko 的评论中:

  • 我可以在“体验资料”中看到我的用户,我可以看到我对网站的访问。
  • 我知道这个用户确实有我的其他方面信息,因为它触发了一些代码。
  • 我可以在 mongo Db 中找到我的用户(从体验配置文件页面中的查询字符串中取出的 ID)
  • 但是当我查看 mongoDb 中的用户时,附加信息不存在。
  • 一些联系人记录有这个数据,但其他人没有

因此,将新信息写入 mongo 似乎是一个问题......有没有人有任何帮助或类似的经验?

回答1

经过大量的调试、摆弄和测试,我终于明白了这一点。 事实证明,我的问题不是写入 mongo,而是在写入后从 mongo 中读取。

sitecore 文档似乎(像往常一样)完全错过了这个工作的一个相当基本的部分。 它指出的文档大约有三分之一:

public EmployeeData() { base.EnsureAttribute<string>(FIELD_EMPLOYEE_ID); }

“EnsureAttribute”方法相当于声明一个值类型变量。


好吧,这是非常具有误导性的。 这个EnsureAttribute似乎做的是将构面的数据从mongo 加载到当前类中。 如果您没有为构面中的每个属性执行此操作,则它不会从 mongoDb 设置值! 这是我的错误,我没有“确保”班级中的每个财产。

所以发生的事情是,

  • 我将我的数据放入 facet
  • 分面数据保留在 Session 中,我可以看到、访问它、更改它等。
  • 数据最终会刷新到 mongo(如果必须,则为 xDb)
  • 用户返回,系统正确识别(无需识别用户SC_ANALYTICS_GLOBAL_COOKIE为您完成此操作)
  • 但除非您“确保”它,否则它不会加载数据(从 mongo 中取出并返回到会话中)。

因此, EnsureAttribute不会“声明值类型” (在我看来这是完全错误的)它将数据从 mongodb 加载到当前Session

回答2

我认为您在这里可能缺少的步骤是用于识别已知联系人的Tracker.Current.Session.Identify()方法。 Tracker api 中的数据仅持续当前会话,您需要将联系人加载到会话中。

xDB 的实现依赖于联系人在访问站点时识别自己的身份,例如通过登录或注册。

一旦他们登录,您就可以使用唯一标识符,例如电子邮件地址,并将其传递给识别方法 - Tracker.Current.Session.Identify("Email Address of the visitor")

调用此方法后,如果用户之前已标识自己,则联系人数据将加载到当前会话中,并且任何现有的方面信息都将在 Tracker Api 中可用。

回答3

您的问题在于您如何拉取联系人:如果您在页面请求中,您应该通过 Tracker.Current.Contact 访问当前联系人。 您的代码不在页面请求中,但用户可能有实时会话,请使用具有上述方法的 ContactManager。 如果联系人现在不在实时会话中,您应该使用 ContactRepository。 在此处查看有关如何使用它的示例。 复制自 https://sitecore.stackexchange.com/questions/3319/why-are-custom-xdb-facets-being-overwritten-on-session-end 由 Dmitry Shevchenko 回答。

受限制的 HTML

  • 允许的HTML标签:<a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • 自动断行和分段。
  • 网页和电子邮件地址自动转换为链接。

相关推荐
  • Sitecore 8 EXM 从列表管理器添加联系人到列表(Sitecore 8 EXM add a contact to list from listmanager)
    问题 我正在使用 Sitecore 8 和新的电子邮件体验管理器模块。 我已将来自列表管理器的空列表配置为时事通讯电子邮件作为收件人。 通过自制表格订阅时事通讯时,我会收到一个电子邮件地址和一个姓名。 现在我想用这个邮件和名字建立一个新的联系人,并通过代码将它添加到我的列表管理器中的列表中。 有什么办法可以通过 api 调用此列表并向其添加联系人吗? 回答1 我遇到了完全相同的问题,即列表管理器在将联系人添加到收件人列表后报告 0 个联系人。 我更仔细地调查了这个问题,发现将联系人添加到收件人列表实际上只是在“sitecore_analytics_index”索引中的联系人上设置一个字段(假设您使用 Mongo/XDB 作为底层存储)。 具体而言,Sitecore 应使用值“ContactLists:{recipientListGuid}”更新联系人文档中的“contact.tags”字段。 我尝试用 Luke 打开索引以验证该字段确实未在索引中设置。 该索引位于 C:\inetpub\wwwroot[站点名称]\Data\indexes\sitecore_analytics_index。 这使我得出结论,您必须在将联系人添加到收件人列表后保存该联系人。 总结一下,以下代码对我有用: var ecm = EcmFactory.GetDefaultFactory()
  • 使客户端JWT会话无效(Invalidating client side JWT session)
    问题 我已经阅读了很多有关JWT的知识,以及如何通过JWT创建“无状态”会话。 我理解的要点是,由于签名和到期,您基本上可以将整个会话发送给客户端保存,而服务器不必维护数据库来记住会话。 我不明白的是,如果您的用户需要注销,或者您需要在到期前使​​会话无效,会发生什么? 从技术上讲,您可以指示浏览器从客户端删除它,但您不能确定这是否真的发生了。 令牌本身在技术上仍然有效,如果不遵循您的删除说明,它仍然可以使用。 这种理解是否正确? 如果是这样,这不是客户端会话管理的一个巨大错误吗? 除了让服务器存储会话或缩短到期时间之外,还有什么方法可以克服这个问题? 回答1 在JWT令牌到期之前使JWT令牌失效有多种原因:删除/阻止/暂停帐户,更改密码,更改权限,由admin用户注销。 所以你的问题是关于主题的 根据您的用例,有几种技术可以应用或组合 1)从本地存储中删除客户端令牌 2)令牌黑名单:存储在注销和过期时间之间的令牌,标记过期并在每个请求中检查它。 使用唯一标识符jti或包含上次登录日期并在iat发布以删除旧令牌 它需要服务器存储。 如果您不希望撤销太多令牌,您也可以使用内存中的黑名单。 你只需要更新用户和关键数据后设置的条目currentTime - maxExpiryTime < lastLoginDate (iat)‌ 当currentTime - maxExpiryTime
  • 优化下一个和上一个元素的查询(Optimizing queries for the next and previous element)
    问题 我正在寻找无需运行完整查询即可检索记录的下一条和上一条记录的最佳方法。 我有一个完全实施的解决方案,并想知道是否有更好的方法来做到这一点。 假设我们正在为一个虚构的蔬菜水果商建立一个网站。 除了他的 HTML 页面之外,他每周都想在他的网站上发布一份特价商品列表。 他希望这些报价位于实际的数据库表中,并且用户必须能够以三种方式对报价进行排序。 每个项目还必须有一个详细信息页面,其中包含有关报价的更多文本信息以及“上一个”和“下一个”按钮。 “上一个”和“下一个”按钮需要根据用户为列表选择的排序指向相邻条目。 (来源:pekkagaiser.com) 显然,在第一个示例中,“Tomatoes, Class I”的“next”按钮必须是“Apples, class 1”,在第二个示例中必须是“Pears, class I”,而在第三个示例中没有。 详细视图中的任务是确定下一个和上一个项目,而无需每次都运行查询,将列表的排序顺序作为唯一可用的信息(假设我们通过 GET 参数?sort=offeroftheweek_price ,并忽略安全隐患)。 显然,简单地将下一个和上一个元素的 ID 作为参数传递是第一个想到的解决方案。 毕竟,此时我们已经知道 ID。 但是,这不是这里的一个选项——它可以在这个简化的例子中工作,但在我的许多现实世界用例中却不是。 我目前在 CMS
  • 无效的JSON Web令牌(Invalidating JSON Web Tokens)
    问题 对于我正在研究的一个新的node.js项目,我正在考虑从基于cookie的会话方法切换(通过这种方式,我的意思是将ID存储到包含在用户浏览器中的用户会话的键值存储中)到使用JSON Web令牌(jwt)的基于令牌的会话方法(无键值存储)。 该项目是一个利用socket.io的游戏-在单个会话(web和socket.io)中会有多个通信渠道的情况下,使用基于令牌的会话将非常有用。 如何使用jwt方法从服务器提供令牌/会话无效? 我还想了解在这种范式下应该注意哪些常见(或不常见)的陷阱/攻击。 例如,如果此范例易受与基于会话存储/ Cookie的方法相同/不同类型的攻击的影响。 因此,说我有以下内容(适应于此): 会话商店登录: app.get('/login', function(request, response) { var user = {username: request.body.username, password: request.body.password }; // Validate somehow validate(user, function(isValid, profile) { // Create session token var token= createSessionToken(); // Add to a key-value database
  • RESTful身份验证(RESTful Authentication)
    问题 RESTful身份验证是什么意思,它如何工作? 我在Google上找不到很好的概述。 我唯一的理解是您在URL中传递了会话密钥(记住的),但这可能是非常错误的。 回答1 如何在RESTful客户端-服务器体系结构中处理身份验证是一个有争议的问题。 通常,它可以通过以下方式在HTTP上的SOA中实现: 通过HTTPS进行HTTP基本身份验证; Cookies和会话管理; HTTP标头中的令牌(例如OAuth 2.0 + JWT); 使用其他签名参数的查询身份验证。 您必须调整甚至更好地混合使用这些技术,才能最好地匹配您的软件体系结构。 每个身份验证方案都有自己的PRO和CON,具体取决于您的安全策略和软件体系结构的目的。 通过HTTPS进行HTTP基本身份验证 大多数Web服务都使用基于标准HTTPS协议的第一个解决方案。 GET /spec.html HTTP/1.1 Host: www.example.org Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 该方法易于实施,默认情况下在所有浏览器上都可用,但存在一些已知的缺点,例如浏览器上显示的可怕的身份验证窗口将持续存在(此处没有类似LogOut的功能),服务器端的额外CPU消耗,以及用户名和密码(通过HTTPS)传输到服务器的事实(在键盘输入过程中让密码仅保留在客户端
  • 使用无扩展名 URL 的优点是什么?(What are the pros for using extension-less URLs?)
    问题 使用无扩展 URL 的优点是什么? 例如,我为什么要改变... http://yoursite.com/mypage.html http://yoursite.com/mypage.php http://yoursite.com/mypage.aspx 至... http://yoursite.com/mypage 是否可以为每个页面提供无扩展名的 URL? 更新: 无扩展名的 URL 对站点安全性更好吗? 回答1 无扩展 URL 的原因是它与技术无关。 如果您想更改内容的呈现方式,则不必更改 URL。 W3:酷 URI 不会改变 文件扩展名这是一个很常见的。 “cgi”,甚至“.html”都会改变。 您可能在 20 年内不会在该页面上使用 HTML,但您可能希望今天指向它的链接仍然有效。 制作指向 W3C 站点的链接的规范方式不使用扩展名.... 结论保留 URI 使其在 2、20 或 200 年甚至 2000 年后仍然存在显然并不像听起来那么简单。 然而,在整个网络上,网站管理员都在做出决定,这将使他们在未来变得非常困难。 通常,这是因为他们使用的工具的任务是呈现当前最佳站点,而没有人评估过当事情发生变化时链接会发生什么。 然而,这里的信息是,很多事情都可以改变,而您的 URI 可以而且应该保持不变。 只有当您考虑如何设计它们时,它们才能做到。 回答2
  • JWT(JSON Web令牌)自动延长有效期(JWT (JSON Web Token) automatic prolongation of expiration)
    问题 我想对我们的新REST API实施基于JWT的身份验证。 但是,由于在令牌中设置了有效期,是否可以自动延长有效期? 我不希望用户在此期间内正在使用该应用程序的情况下,每隔X分钟登录一次。 那将是一个巨大的用户体验失败。 但是,延长有效期会创建一个新令牌(旧令牌在过期之前仍然有效)。 在每个请求之后生成一个新令牌对我来说听起来很愚蠢。 当多个令牌同时有效时,听起来像是一个安全问题。 当然,我可以使用黑名单来使旧的用过的无效,但是我需要存储令牌。 JWT的好处之一是无需存储。 我发现Auth0是如何解决它的。 他们不仅使用JWT令牌,而且还使用刷新令牌:https://auth0.com/docs/tokens/refresh-tokens 但是同样,要实现此功能(不使用Auth0),我需要存储刷新令牌并保持其过期。 那么,真正的好处是什么? 为什么不只有一个令牌(而不是JWT)并在服务器上保留到期时间呢? 还有其他选择吗? 使用JWT是否不适合这种情况? 回答1 我在Auth0工作,并参与了刷新令牌功能的设计。 这完全取决于应用程序的类型,这是我们推荐的方法。 网路应用程式 一个好的模式是在令牌过期之前刷新它。 将令牌到期时间设置为一周,并在用户每次打开Web应用程序时以及每隔一小时刷新一次令牌。 如果用户超过一个星期没有打开应用程序,则他们将不得不再次登录
  • 如何验证/保护/认证基于JavaScript的POST请求?(How can I validate/secure/authenticate a JavaScript-based POST request?)
    问题 我正在帮助开发的产品基本上可以像这样工作: Web发布者会在其站点上创建一个新页面,其中包含来自我们服务器的<script> 。 当访问者到达该新页面时,该<script>收集该页面的文本内容,并通过POST请求(跨域,使用<iframe>内的<form>将其发送到我们的服务器。 我们的服务器处理文本内容,并返回响应(通过JSONP),该响应包括HTML片段,该片段列出了指向Web上相关内容的链接。 此响应将被缓存并提供给后续访问者,直到我们从同一URL接收到另一个包含文本内容的POST请求,此时我们将重新生成“新”响应。 这些POST仅在我们的缓存的TTL过期时才发生,这时服务器会表明这一点,并提示页面上的<script>再次收集并发布文本内容。 问题在于该系统似乎天生就不安全。 从理论上讲,任何人都可以欺骗将页面内容发送到我们服务器的HTTP POST请求(包括Referer标头,因此我们不能仅仅检查它)。 这可以包括任何文本内容,然后我们将使用这些文本内容来生成该页面的相关内容链接。 确保此安全性的主要困难是我们的JavaScript是公开可见的。 我们不能使用任何类型的私钥或其他隐式标识符或模式,因为这不是秘密。 理想情况下,我们需要一种方法以某种方式验证与特定网页相对应的POST请求是真实的。 我们不能只是抓取网页并将内容与已发布内容进行比较
  • OAuth2.0令牌异常行为(无效凭据401)(OAuth2.0 token strange behaviour (Invalid Credentials 401))
    问题 通常,Google OAuth2.0机制运行良好。 用户确认有权访问具有选定范围的Google帐户。 检索刷新令牌并将其保存到长时间存储中。 每次需要时(如果访问令牌已过期),都会检索访问令牌并将其用于访问API。 但是有时(到目前为止,在超过6个月的时间内只有两次),我经历了奇怪的行为: 向Google API发出的请求返回无效凭据(401)错误。 刷新访问令牌(使用存储的刷新令牌)无济于事。 这是测试此问题时获得的一些结构化输出: + ------------------------------------------------------------------------- + | 1.TRYING TO REFRESH THE TOKEN. | | 2.DONE REFRESHING THE TOKEN. | + ------------------------------------------------------------------------- + | access: **************************************************** | | refresh: ********************************************* | | expires: 3600 | | created
  • 禁用了Cookie的PHP会话,可以正常工作吗?(PHP Sessions with disabled cookies, does it work?)
    问题 今天,我接受了Skype的PHP开发人员面试,其中一个问题是关于Cookies和PHP Sessions的问题。 问题是,如果在用户浏览器中禁用了Cookie,是否可以设置和读取,使用PHP会话? 我没有告诉他们,因为默认情况下PHP会话依赖于设置会话cookie。 当PHP会话启动时,将使用默认名称PHPSESSID设置新的会话Cookie,并且该cookie保存该会话ID的值,例如:ftu63d8al491s5gatuobj39gk7然后在apache服务器上的tmp文件夹文件中创建sess_ftu63d8al491s5gatuobj39gk7并保存该会话的内容,例如:test1 | s:12:“ SessionTest1”; test2 | s:12:“ SessionTest2”; 他们告诉我事实并非如此,即使用户禁用了浏览器中的cookie,您也可以使用PHP会话。 然后我告诉他们您可以执行此操作,但是会话ID将作为GET变量通过URL传递。 这并不安全,您必须在php.ini中进行设置。 他们在谈论即使浏览器中禁用了Cookie,您也可以如何使用PHP会话。 还有,如果我们正在建立网上商店,并且有一个奶奶使用我们的网上商店并禁用cookie,而她只是不在乎,那该怎么办。 PHP会话很棒,因为即使用户禁用了Cookie,您也可以使用它们。 我就像wtf,wtf
  • 违反基于JWT的服务器是否更具破坏性?(Are breaches of JWT-based servers more damaging?)
    问题 更新:我已经完成了对这个问题的研究,并发表了一篇冗长的博客文章,解释了我的发现:JWT的潜行漏洞。 我解释了使用JWT进行本地身份验证的大努力是如何遗漏了一个关键细节:必须保护签名密钥。 我还解释说,除非您愿意竭尽全力保护密钥,否则最好通过Oauth或使用传统的会话ID来委派身份验证。 我已经看到了很多有关JSON Web令牌安全性的讨论-重播,吊销,数据透明性,令牌指定的算法,令牌加密,XSS,CSRF-但我还没有看到对依赖于Web令牌所带来的风险的任何评估签名密钥。 如果有人违反了服务器并获得了JWT签名密钥,那么在我看来,此人此后可以使用该密钥伪造未过期的JWT并秘密获得访问权限。 当然,服务器可以在每个请求上查找每个JWT以确认其有效性,但是服务器完全使用JWT,因此不必这样做。 服务器可以确认IP地址,但是如果不信任JWT,这还涉及一个查找,并且显然这样做会妨碍可靠的移动访问。 将此与违反基于会话ID的服务器的情况进行对比。 如果此服务器正在对密码进行哈希处理,则攻击者必须在每个用户过期之前先捕获并分别为每个用户使用会话ID。 如果服务器仅存储会话ID的哈希,则攻击者将不得不向服务器写入内容以确保访问权限。 无论如何,攻击者的优势似乎较少。 我发现了一种使用JWT的体系结构而没有这个缺点。 反向代理位于外部不受信任的客户端和内部的微服务后端集合之间,这在Nordic
  • 可以缓存JSON以提高性能/加载时间吗?(Possible to cache JSON to increase performance / load time?)
    问题 我正在使用JSON文件自动填充下拉列表。 它绝非庞大(3000行并且还在不断增长),但是刷新页面所花费的时间变得非常引人注目。 首次加载页面时,将读取JSON,具体取决于用户选择了哪个选项,从而决定了使用JSON的哪一部分来填充下拉列表。 然后将其加载到每次刷新或菜单选择之后。 是否可以以某种方式缓存值以防止需要一次又一次地重新加载它? 谢谢。 编辑:更多信息:它本质上是一个单位转换器。 JSON包含所有详细信息。 例如,当用户选择“临时”时,将进行呼叫并填充列表。 转换完成后,您可以整天运行临时转换,它们会很好,但是每当用户更改转换类型时,现在,页面长度就会刷新,并且会花费大量时间。 回答1 不幸的是,我不了解PHP中的标准化全局缓存机制。 本文说,5.5版开始,核心PHP中已包含第三方加速器Optimizer Plus。 不知道您使用的是哪个版本,但是您可以尝试使用。 另一方面,您是否考虑过安德鲁(Andrew)指出的文件存储? 在这种情况下,我认为它与$_SESSION结合可以真正为您提供帮助。 让我给您一个示例,该示例将与您现有的JSON数据一起使用: 服务器端 将JSON数据存储在PHP服务器上的.json文件中: { "data": "some data", "data2": "more data", "data3": [ ... ], etc. } 注意
  • Facebook Oauth 2.0访问令牌会过期吗?(Do Facebook Oauth 2.0 Access Tokens Expire?)
    问题 我正在Facebook中使用Oauth 2.0授权,并且想知道Facebook发出的访问令牌是否会过期。 如果是这样,是否有办法请求长寿命访问令牌? 回答1 经过一番挖掘,我发现了这一点。 似乎是答案: 更新(11 / April / 2018) 该令牌将在约60天后过期。 当使用您的应用的人向Facebook的服务器发出请求时,令牌将每天刷新一次,最多90天。 所有访问令牌都需要在使用您的应用的人的同意下每90天更新一次。 Facebook更改公告(10/04/2018) Facebook更新了令牌到期页面(10/04/2018) offline_access:使您的应用程序可以随时代表用户执行授权的请求。 默认情况下,大多数访问令牌会在很短的时间后过期,以确保应用程序仅在用户积极使用应用程序时才代表用户发出请求。 此权限可以使我们的OAuth端点返回的访问令牌长期存在。 其请求的权限值。 http://developers.facebook.com/docs/authentication/permissions 更新 offline_access权限已被删除。 https://developers.facebook.com/docs/roadmap/completed-changes/offline-access-removal/ 回答2 试试这个可能对您有帮助
  • 当“隐式”流程运行良好时,为什么在OAuth2中存在“授权码”流程?(Why is there an “Authorization Code” flow in OAuth2 when “Implicit” flow works so well?)
    问题 通过“隐式”流程,在资源所有者(即用户)授予访问权限后,客户端(可能是浏览器)将获得访问令牌。 但是,通过“授权码”流程,客户端(通常是Web服务器)仅在资源所有者(即用户)授予访问权限后才获得授权码。 客户端使用该授权代码,然后再次调用API,同时传递client_id和client_secret以及授权代码,以获取访问令牌。 一切都在这里描述。 两种流程具有完全相同的结果:访问令牌。 但是,“隐式”流程要简单得多。 问题:当“隐式”流接缝很好时,为什么还要打扰“授权码”流? 为什么不同时对Web服务器使用“隐式”? 对于提供商和客户而言,这都是更多的工作。 回答1 tl; dr:这都是出于安全原因。 OAuth 2.0希望满足以下两个条件: 您希望允许开发人员使用非HTTPS重定向URI,因为并非所有开发人员都具有启用SSL的服务器,并且如果这样做的话,并非总是正确配置(非自签名,受信任的SSL证书,同步的服务器时钟...)。 您不希望黑客能够通过拦截请求来窃取访问/刷新令牌。 详情如下: 由于安全原因,隐式流仅可能在浏览器环境中进行: 在隐式流中,访问令牌作为散列片段(而不作为URL参数)直接传递。 关于散列片段的重要一件事是,一旦您访问了包含散列片段的链接,则只有浏览器才知道该散列片段。 浏览器会将哈希片段直接传递到目标网页(重定向URI /客户端的网页)。
  • OAuth 2与OAuth 1有何不同?(How is OAuth 2 different from OAuth 1?)
    问题 简单来说,有人可以解释OAuth 2和OAuth 1之间的区别吗? OAuth 1现在过时了吗? 我们应该实施OAuth 2吗? 我看不到OAuth 2的许多实现; 大多数人仍在使用OAuth 1,这使我怀疑OAuth 2可以使用了。 是吗? 回答1 Eran Hammer-Lahav在解释OAuth 2.0简介中的大部分差异方面做得非常出色。 总结一下,这是主要的区别: 更多的OAuth流,可以更好地支持基于非浏览器的应用程序。 这是对不是基于浏览器的客户端应用程序对OAuth的主要批评。 例如,在OAuth 1.0中,桌面应用程序或移动电话应用程序必须指示用户打开其浏览器以访问所需的服务,对该服务进行身份验证并将令牌从该服务复制回该应用程序。 这里主要的批评是反对用户体验。 使用OAuth 2.0,应用程序现在有了新的方式来获得用户的授权。 OAuth 2.0不再要求客户端应用程序具有加密功能。 这可以回溯到旧的Twitter Auth API,该API不需要应用程序使用HMAC哈希令牌和请求字符串。 使用OAuth 2.0,应用程序只能使用通过HTTPS发出的令牌来发出请求。 OAuth 2.0签名要简单得多。 不再需要特殊的解析,排序或编码。 OAuth 2.0访问令牌是“短暂的”。 通常,OAuth 1.0访问令牌可以存储一年或更长时间
  • ECS.Day5笔记
    阿里云高校计划Day5笔记 一、ECS之初体验(Linux)1.1 背景知识1.2 远程登录ECS服务器1.3 使用阿里云控制台管理ECS实例1.4 查看ECS实例磁盘1.5 重置ECS实例登陆密码1.6 重启ECS实例1.7 如何选购ECS实 二、云服务器的数据备份和恢复2.1 背景知识2.2 ECS数据盘分区以及挂载2.3 ECS数据盘快照的创建2.4 ECS磁盘回滚2.5 创建自定义镜像2.6 更换系统盘 三、云数据库管理3.1 背景知识3.2 访问阿里云RDS管理控制台3.3 创建RDS数据库账号3.4 创建RDS数据库3.5 登录RDS数据库3.6 导入测试数据3.7 查看诊断报告 四、数据库上云迁移的实现4.1 查询源数据库4.2 建立目标数据库4.3 数据库迁移4.4 查阅迁移结果 五、云存储OSS使用5.1 背景介绍5.2 查看图片分享网站5.3 上传图片文件5.4 使用OSS存储图片分享网站 六、使用云存储OSS的API上传和下载文件6.1 背景知识6.2 查看OSS环境6.3 调用OSS API上传小文件6.4 调用OSS API下载小文件6.5 调用OSS API删除Objec6.6 创建OSS Bucket6.7 使用OSS管理控制台上传文件6.8使用OSS管理控制台查看Object文件6.9 使用OSS管理控制台删除Object文件6.10 删除OSS
  • 是什么导致全局Tomcat / JVM变慢?(What could cause global Tomcat/JVM slowdown?)
    问题 我在Tomcat 7 / Java 7上运行几个(约15个)Java EE类的Web应用程序实例(休眠4 + Spring + Quartz + JSF + Facelets + Richfaces)时遇到一个奇怪但严重的问题。 该系统运行良好,但是经过很长一段时间后,同一时间所有应用程序实例突然遭受响应时间增加的困扰。 基本上,该应用程序仍然可以运行,但是响应时间大约是原来的三倍。 这是两个图,显示了两个示例实例的两个特定的简短工作流程/操作(登录,研讨会访问列表,ajax刷新此列表,注销;下一行只是ajax刷新的请求时间)的响应时间。的应用程序: 如您所见,应用程序的两个实例在同一时间“爆炸”并保持缓慢。 重新启动服务器后,一切恢复正常。 该应用程序的所有实例同时“爆炸”。 我们将会话数据存储到数据库中,并将其用于集群。 我们检查了会话的大小和数量,并且两者都很低(这意味着在其他具有其他应用程序的服务器上,我们有时会拥有更大和更多的会话)。 集群中的另一个Tomcat通常会保持快速运行几个小时,并且在这个随机的时间之后,它也会“消失”。 我们使用jconsole检查了堆大小,并且主堆大小保持在2.5到1 GB之间,数据库连接池基本上充满了免费连接以及线程池。 最大堆大小为5 GB,也有足够的烫发空间。 负载不是特别高; 主CPU上只有大约5%的负载。 服务器不交换。
  • [安全 】JWT初学者入门指南
    令牌身份验证,OAuth或JSON Web令牌的新手?这是一个很好的起点!首先,什么是JSON Web令牌,或JWT(发音为“jot”)?简而言之,JWT是用于令牌认证的安全且值得信赖的标准。JWT允许您使用签名对信息(称为声明)进行数字签名,并且可以在以后使用秘密签名密钥进行验证。什么是令牌认证?应用程序确认用户身份的过程称为身份验证。传统上,应用程序通过会话cookie保持身份,这些cookie依赖于服务器端存储的会话ID。在此结构中,开发人员被迫创建独特且特定于服务器的会话存储,或实现为完全独立的会话存储层。令牌认证是一种更现代的方法,设计解决了服务器端会话ID无法解决的问题。使用令牌代替会话ID可以降低服务器负载,简化权限管理,并提供更好的工具来支持分布式或基于云的基础架构。在此方法中,为用户提供可验证凭据后会生成令牌。初始身份验证可以是用户名/密码凭据,API密钥,甚至来自其他服务的令牌。(Stormpath的API密钥身份验证功能就是一个例子。)有兴趣了解更多?查看此博客文章,了解如何使用令牌扩展用户管理或完整的产品文档。JWT的剖析如果您在野外遇到JWT,您会注意到它分为三个部分,标题,有效负载和签名。(随着我们剖析JWT的解剖结构,请关注Stormpath的开源Java JWT工具!)以下是典型JWT的示例
  • [安全 】JWT初学者入门指南
    令牌身份验证,OAuth或JSON Web令牌的新手?这是一个很好的起点!首先,什么是JSON Web令牌,或JWT(发音为“jot”)?简而言之,JWT是用于令牌认证的安全且值得信赖的标准。JWT允许您使用签名对信息(称为声明)进行数字签名,并且可以在以后使用秘密签名密钥进行验证。什么是令牌认证?应用程序确认用户身份的过程称为身份验证。传统上,应用程序通过会话cookie保持身份,这些cookie依赖于服务器端存储的会话ID。在此结构中,开发人员被迫创建独特且特定于服务器的会话存储,或实现为完全独立的会话存储层。令牌认证是一种更现代的方法,设计解决了服务器端会话ID无法解决的问题。使用令牌代替会话ID可以降低服务器负载,简化权限管理,并提供更好的工具来支持分布式或基于云的基础架构。在此方法中,为用户提供可验证凭据后会生成令牌。初始身份验证可以是用户名/密码凭据,API密钥,甚至来自其他服务的令牌。(Stormpath的API密钥身份验证功能就是一个例子。)有兴趣了解更多?查看此博客文章,了解如何使用令牌扩展用户管理或完整的产品文档。JWT的剖析如果您在野外遇到JWT,您会注意到它分为三个部分,标题,有效负载和签名。(随着我们剖析JWT的解剖结构,请关注Stormpath的开源Java JWT工具!)以下是典型JWT的示例
  • 休眠或JDBC(Hibernate or JDBC)
    问题 我有一个胖客户端,带有25个表和约15个JInternalFrames(表的数据输入表单)的架构的java swing应用程序。 我需要为DBMS交互选择直接的JDBC或ORM(在这种情况下为Spring框架休眠)的设计选择。 应用程序的构建将在将来发生。 对于这种规模的项目,冬眠会显得过分杀伤力吗? 对于肯定或否定答案的解释将不胜感激(如果需要,甚至可以采用其他方法)。 TIA。 回答1 好问题,没有一个简单的答案。 在多年使用多个项目后,我曾经是Hibernate的忠实拥护者。 我曾经相信任何项目都应默认为休眠状态。 今天我不太确定。 Hibernate(和JPA)在某些方面非常有用,尤其是在开发周期的早期。 使用Hibernate进行操作要比使用JDBC快得多。 您可以免费获得许多功能-缓存,乐观锁定等。 另一方面,它有一些隐性成本。 开始时,Hibernate看起来非常简单。 遵循一些教程,在您的课程上添加一些注释-您就可以保持自己的持久性。 但这并不简单,并且要能够编写出良好的代码,需要对它的内部工作原理和数据库设计有充分的了解。 如果您只是刚开始,您可能不知道以后可能会遇到的某些问题,因此这里是不完整的列表。 表现 运行时性能足够好,我还没有看到休眠是生产环境中性能不佳的原因的情况。 问题在于启动性能以及它如何影响您的单元测试时间和开发性能。 当休眠加载时