让编译能够通过是最基本的要求了。 是不会运行有错误存在的。 https://www.usreio.com/t/topic/302
让编译能够通过是最基本的要求了。 是不会运行有错误存在的。 https://www.usreio.com/t/topic/302
在国内小朋友的帮助下,已经初具雏形了。 为了帮助大家在签证时候的签证行政审查,我们做了一个小工具希望能够帮助到所有在路上的人。 要改的还在继续,我们还在持续推进喔。 https://www.usvisatrack.com/
我们在使用 Spring JPA 测试项目启动的时候,得到下面的错误: Unable to acquire JDBC Connection 问题和解决 出现这个问题的主要原因是我们在资源文件夹中还有一个 hibernate.properties 文件。 这个文件中配置了 Hibernate 的数据库参数。 因为这个文件的存在,对我们 Spring JPA 使用的数据源进行了干扰。 解决办法就是删除 Hibernate 的属性配置文件。 将上面的属性配置文件删除即可。 https://www.ossez.com/t/spring-unable-to-acquire-jdbc-connection/14133
Spring 进行测试的时候提示的错误信息如下: SEVERE: Caught exception while closing extension context: org.junit.jupiter.engine.descriptor.JupiterEngineExtensionContext@c63c11ed java.lang.IllegalStateException: Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test 问题和解决 这个问题的主要原因是测试的包和项目的包的路径可能不一致。 这将会导致测试没有办法找到有关 Spring 有关的配置。 对比上面的图,我们就可以看到这个问题。 解决方法就是确定包的路径是一致的,这样 Spring 的测试类可以找到 Spring 有关的配置。 https://www.ossez.com/t/spring-unable-to-find-a-springbootconfiguration/14132
属性文件乱码通常是中文乱码,在英文下通常没有这个问题。 如上图显示的,中文字符在属性文件中读取后会显示为乱码. 问题和解决 导致这个问题的主要原因是属性文件如果你不进行设置,那么将会默认使用 ISO-8859-1 字符集来存储的。 通常我们也不建议在属性文件中过多使用中文,一般来说属性文件都是一些配置,如果需要中文的配置可以存储在其他的文件中。 如果非要使用,也是可以的。 不修改字符集 在不修改字符集的情况,将中文字符使用 Unicode 来表示就可以了。 如上面的例子,使用下面的字符。 name = \u5C5E\u6027\u6587\u4EF6 Inject a value to a static field 在程序输出的时候就可以显示成中文了。 转换成 UTF-8 编码 可以把属性文件转换成 UTF-8 编码。 这个 IDEA 能够很好的帮我们进行转换。 选择文件编码,然后选择 UTF-8,然后选择后面的选项。 然后在更新过代码的属性文件中输中文。 再次运行后,我们就可以看到能够正常显示中文了。 如上图完成修改后,就可以显示中文了。 https://www.ossez.com/t/java/14131
在 Spring JPA 1 对多查询的时候出现死循环的问题。 如下图所示: 所有的配置都是正确的的,就是没有办法获得数据,并且出现死循环 问题和解决 因为使用lombak的 @Data ,在toString()方法中产生死循环。 因为我们使用了 @Data 注解。 所有让 lombok 定义的 @ToString 类将会实现一个 toString() 方法。 在默认的情况下,将会指向类的名称,同时和每一个字段。 例如在使用 lazy @OneToMany 方法调用 hashCode() 的时候,fetch 可能有所有的实体类,这个对应用程序的运行可能产生非常大的性能问题。 同时,如果你在事务以外使用的话,可能会得到 LazyInitializationException 异常。 如果查询一个User实体,并打印,打印调用的是toString() 方法,toString()方法里面又有关联Dept对象。 所以导致 User 和子对象之间的两个对象互相调用并打印,形成一个递归调用,最后堆栈溢出。 基于上面的考虑,我们认为 @EqualsAndHashCode 和@Data 不应该应用在 JPA 的实体类上使用。 @ToString 还是可以使用的,因为我们可以使用 @ToString.Exclude 来设置不需要的字段或者使用 @ToString(onlyExplicitlyIncluded = true ) 来移除类, 对于 non-lazy 字段,我们可以使用@ToString.Include 注解。 例如我们的解决方案就是在 JPA 实体类中只使用 @Getter @Setter 注解。 基于上面的原因,这也是很多人建议使用 Lombok 的原因。 我们的理解还是可以使用的,别滥用,别图省事一个 @Data 到头。 https://www.ossez.com/t/spring-lombok/14129
有一个项目启用了 Spring Security,后台使用的是 H2 数据库。 使用用户名和密码登录后没有问题,但登录后提示 ‘X-Frame-Options’ to ‘deny’. 错误。 错误信息如上图。 问题和解决 X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面可否在 <frame>、<iframe>、<embed> 或者 <object> 中展现的标记。站点可以通过确保网站没有被嵌入到别人的站点里面,从而避免点击劫持 攻击。 X-Frame-Options有三种可配置值 X-Frame-Options: DENY X-Frame-Options: SAMEORIGIN X-Frame-Options: ALLOW-FROM https://example.com/ 第一个例子告诉浏览器不要(DENY)把这个网页放在iFrame内,通常的目的就是要帮助用户对抗点击劫持。 第二个例子告诉浏览器只有当架设iFrame的网站与发出X-Frame-Options的网站相同,才能显示发出X-Frame-Options网页的内容。 第三个例子告诉浏览器这个网页只能放在 https://example.com/ 网页架设的iFrame内。 不指定X-Frame-Options的网页等同表示它可以放在任何iFrame内。 X-Frame-Options可以保障你的网页不会被放在恶意网站设定的iFrame内,令用户成为点击劫持的受害人。 如上图所展示的内容,受害者通常是因为点击了来路不明的网页,在这个网页中通常有一个 IFrame 嵌入。 然后攻击者就可以利用这个漏洞来对用户的点击进行劫持。 Spring Security 的启用 在 Spring 中,我们可以使用下面的代码来进行同源性校验。 http.headers().frameOptions().sameOrigin(); 当然,更可以直接禁用这个校验。 针对我们的问题,使用同源性校验就可以满足要求了。 https://www.ossez.com/t/spring-security-x-frame-options-to-deny/14123
尝试使用 H2 数据库创建表,但是老是提示 expected "identifier 这个错误。 问题和解决 经过搜索后才知道,上面的错误是因为我们使用的表名 USER 是 H2 的关键字。 H2 的关键字列表为:Advanced 很明显这里 是一个关键字。 可以: 简单粗暴的对使用的关键字使用单引号 在JDBC 连接中使用 ;NON_KEYWORDS=USER 数据库关键字 到底应不应该使用 USER 作为用户表的命名呢? 搜索了下不同的说法,大部分都认为不应该将用户表的名称命名为 USER ,而应该使用 Person。 根据 ISO/IEC 11179-6:20 中规范的说法,我们应该避免使用 USER 来命名用户表,也不要使用 USERS 来命名。 数据库表的命名可以使用前缀和后缀的方式。 下面是有关的一些实例。 前缀 如果你的表可能超过有 100 个表的话,可以使用定义的前缀来命名,例如: REF_ 为参考表 OE_ 为 Order Entry 相关,这个值针对为物理级别的命名,而不是逻辑级别的 后缀 永远不要使用后缀来命名表,而应该使用后缀来命名其他的东西,但是这也不是绝对的的。 例如针对视图我们可以使用 _V 这个前缀来命名。 _fk 外键 _cac 缓存 _seg Segment _tr 事务 _fn 函数等 总结 针对表的命名没有绝对的统一的说法,但是针对一个公司或者一个项目,最好使用统一命名的标准。 对表进行一些系统性的区分,能够让我们更好的区分用途。 例如: 系统表(S_)可以用来定义系统的基本信息,更多是元数据等,这些数据是有关于系统运行的,通常例如可以定义 系统用户表(S_USER)、系统角色表(S_ROLE)等。 这样可以有效的避免关键字冲突。 很多时候,可能觉得这个是不是有点麻烦呀,很多项目可能不会超过几百个表。 但,免不了一些奇葩项目,有上千个表,经历过一个不是非常复杂的逻辑项目,但是表有 1300 多个,真不知道这个表是怎么建的,并且是各种奇葩的命名都有。 另外,千万别用 tbl 作为前缀来命名表,简直就是脱了裤子放屁,谁不知道你这个表是 tbl? https://www.ossez.com/t/h2-expected-identifier/14122
近期,因为需要研究 Spring Security 的安全机制,因为 Spring Security 说可以帮助避免 CSRF 攻击。 因此特地考古了相关的内容。 简单点解释就是 CSRF 盗用了你的 Cookies 中存的信息,伪造了你的请求。 有关 CSRF 介绍 CSRF(Cross-site request forgery),中文名称:跨站请求伪造,也被称为:one click attack/session riding,缩写为:CSRF/XSRF。 跨站请求伪造 (英语:Cross-site request forgery),也被称为 one-click attack 或者 session riding ,通常缩写为 CSRF 或者 XSRF , 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。 相比,XSS 利用的是用户对指定网站的信任,CSRF 利用的是网站对用户网页浏览器的信任。 CSRF 的威胁 你这可以这么理解CSRF攻击:攻击者盗用了你的身份,以你的名义发送恶意请求。CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账…造成的问题包括:个人隐私泄露以及财产安全。 CSRF这种攻击方式在2000年已经被国外的安全人员提出,但在国内,直到06年才开始被关注,08年,国内外的多个大型社区和交互网站分别爆出CSRF漏洞,如:NYTimes.com(纽约时报)、Metafilter(一个大型的BLOG网站),YouTube和百度HI…而现在,互联网上的许多站点仍对此毫无防备,以至于安全业界称CSRF为“沉睡的巨人”。 相比XSS,CSRF的名气似乎并不是那么大,很多人都认为CSRF“不那么有破坏性”。真的是这样吗? Case 1 这一天,小明同学百无聊赖地刷着Gmail邮件。大部分都是没营养的通知、验证码、聊天记录之类。但有一封邮件引起了小明的注意: 甩卖比特币,一个只要998!! 聪明的小明当然知道这种肯定是骗子,但还是抱着好奇的态度点了进去(请勿模仿)。果然,这只是一个什么都没有的空白页面,小明失望的关闭了页面。一切似乎什么都没有发生…… 在这平静的外表之下,黑客的攻击已然得手。小明的Gmail中,被偷偷设置了一个过滤规则,这个规则使得所有的邮件都会被自动转发到hacker@hackermail.com。小明还在继续刷着邮件,殊不知他的邮件正在一封封地,如脱缰的野马一般地,持续不断地向着黑客的邮箱转发而去。 不久之后的一天,小明发现自己的域名已经被转让了。懵懂的小明以为是域名到期自己忘了续费,直到有一天,对方开出了 $650 的赎回价码,小明才开始觉得不太对劲。 小明仔细查了下域名的转让,对方是拥有自己的验证码的,而域名的验证码只存在于自己的邮箱里面。小明回想起那天奇怪的链接,打开后重新查看了“空白页”的源码: Case 2 假如一家银行用以执行转账操作的URL地址如下: https://bank.example.com/withdraw?account=AccoutName&amount=1000&for=PayeeName 那么,一个恶意攻击者可以在另一个网站上放置如下代码: <img src="https://bank.example.com/withdraw?account=Alice&amount=1000&for=Badman" /> 如果有账户名为Alice的用户访问了恶意站点,而她之前刚访问过银行不久,登录信息尚未过期,那么她就会损失1000资金。 这种恶意的网址可以有很多种形式,藏身于网页中的许多地方。此外,攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛,博客等任何用户生成内容的网站中。这意味着如果服务端没有合适的防御措施的话,用户即使访问熟悉的可信网站也有受攻击的危险。 透过例子能够看出,攻击者并不能通过CSRF攻击来直接获取用户的账户控制权,也不能直接窃取用户的任何信息。他们能做到的,是欺骗用户的浏览器,让其以用户的名义执行操作。 防御 受害者必须依次完成两个步骤: 登录受信任网站A,并在本地生成Cookie。 在不登出A的情况下,访问危险网站B。 看到这里,你也许会说:“如果我不满足以上两个条件中的一个,我就不会受到CSRF的攻击”。是的,确实如此,但你不能保证以下情况不会发生: 你不能保证你登录了一个网站后,不再打开一个tab页面并访问另外的网站。 你不能保证你关闭浏览器了后,你本地的Cookie立刻过期,你上次的会话已经结束。(事实上,关闭浏览器不能结束一个会话,但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了…) 所谓的攻击网站,可能是一个存在其他漏洞的可信任的经常被人访问的网站。 令牌同步模式 令牌同步模式(英语:Synchronizer token pattern,简称STP)。原理是:当用户发送请求时,服务器端应用将令牌(英语:token,一个保密且唯一的值)嵌入HTML表格,并发送给客户端。客户端提交HTML表格时候,会将令牌发送到服务端,令牌的验证是由服务端实行的。令牌可以通过任何方式生成,只要确保随机性和唯一性(如:使用随机种子【英语:random seed】的哈希链 )。这样确保攻击者发送请求时候,由于没有该令牌而无法通过验证。 检查Referer字段 HTTP头中有一个Referer字段,这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时,通常来说,Referer字段应和请求的地址位于同一域名下。以上文银行操作为例,Referer字段地址通常应该是转账按钮所在的网页地址,应该也位于bank.example.com之下。而如果是CSRF攻击传来的请求,Referer字段会是包含恶意网址的地址,不会位于bank.example.com之下,这时候服务器就能识别出恶意的访问。 这种办法简单易行,工作量低,仅需要在关键访问处增加一步校验。但这种办法也有其局限性,因其完全依赖浏览器发送正确的Referer字段。虽然http协议对此字段的内容有明确的规定,但并无法保证来访的浏览器的具体实现,亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器,篡改其Referer字段的可能。 添加校验 token 由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址,所以如果要求在访问敏感数据请求时,要求用户浏览器提供不保存在cookie中,并且攻击者无法伪造的数据作为校验,那么攻击者就无法再执行CSRF攻击。这种数据通常是窗体中的一个数据项。 服务器将其生成并附加在窗体中,其内容是一个伪随机数。当客户端通过窗体提交请求时,这个伪随机数也一并提交上去以供校验。正常的访问时,客户端浏览器能够正确得到并传回这个伪随机数,而通过CSRF传来的欺骗性攻击中,攻击者无从事先得知这个伪随机数的值,服务端就会因为校验token的值为空或者错误,拒绝这个可疑请求。 https://www.ossez.com/t/spring-security-csrf/14121
本文章对如何快速启动一个 启动 Hello Spring Security Boot 应用进行说明。 下载代码 在这个项目中,使用的是 spring.io 的项目生成程序,生成的地址为:https://start.spring.io/starter.zip?type=maven-project&language=java&packaging=jar&jvmVersion=1.8&groupId=example&artifactId=hello-security&name=hello-security&description=Hello%20Security&packageName=example.hello-security&dependencies=web,security 当你双击上面的生产地址,你的浏览器将会访问 Spring.io 的网站,然后从这个网站上生产一个 zip 包下载。 为了方便我们查看代码,我们也将生成的 zip 包上传到我们的代码库中了,地址为:https://src.ossez.com/Cwikius-Spring/Spring-Security-Hello 编译 将所有的内容解压后放到本地,然后使用 IDEA 导入。 当导入成功后应该是没有问题完成编译的。 需要注意的是,有可能你的 JDK 需要安装 17 的版本,因为 Spring 的最新版本需要 JDK 17 了。 如果你的 JDK 版本为 11 的话,你可以在这里直接修改为 11 也是可以运行的。 运行 这个项目非常简单,只有一个可运行类,直接单击这个类右键运行即可。 在 IDEA 的控制台上,你可以看到生成的密码。 当然你也可以按照官方提示中使用 mvn 的运行方式。 运行生成的密码如下。 测试 通过浏览器访问 8080 端口 用户名为:user 密码为控制台生成的密码。 如一切正确,你的系统将会允许你进行登录,至此,我们完成了第一个 Spring Security 项目的运行。 登录后的界面会显示一个错误提示的空白界面,这是因为我们没有为这个项目定义 index 页面的内容。 如果输入的用户名和密码不正确的话,你将会在网页上得到错误的提示。 https://www.ossez.com/t/hello-spring-security-boot/14119