2019-08-30 17:58
@reborn797 你没在 controller 中调用 render 方法吧?
或者 render 方法的参数错了
还有一个可能是拦截器拦截了请求,将 render 导向了别的地方
2019-08-30 17:56
@要输就输给追求 应该是正解
@MarlonBrando 你的 url 不要指向 .html 文件,而是要指向配置的路由,例如:
http://localhost/action
2019-08-30 16:32
@reborn797 return false 报错,就要根据异常信息,先去解决这个错误
2019-08-30 11:23
@66666666 解决就好, jfinal 几乎所有地方都是可以扩展的,例如 ActionHandler 也可以扩展,这样甚至就接管了整个 jfinal
所有 render 通过 RenderFactory 也可以扩展定制
Db 类的行为也可以通过继承 DbPro 来扩展,极度灵活、强大
2019-08-30 11:13
这个是第三方 cos 的问题,不是 jfinal 内部所能控制的
因此,我升级了 cos 版本,解决了这个问题,升级 cos 到 2019.8 版本即可,具体的改进见 gitee:
https://gitee.com/jfinal/cos/commit/8d26eec61f0d072a68bf7393cf3a8544a1112130
https://gitee.com/jfinal/cos/commit/5eb23d6e384abaad19faa7600d14c9a2f525946a
攻击者是利用请求数据格式不对,在上传文件的过程中让 cos 抛出异常,而 cos 抛出异常以后并没有删掉已经上传的一部分内容
解决思路也就极其简单:
在上传逻辑的最外层用 try catch, 在 catch 块中无条件删除所有已经上传的部分内容
https://gitee.com/jfinal/cos/commit/8d26eec61f0d072a68bf7393cf3a8544a1112130
jfinal 是不可能犯这种低极错误的,但难保第三方出问题, 所以 jfinal 诞生 8 年多以来,坚持让 jfinal 不强制依赖任何第三方,对于在部分可选功能时 provided 使用的第三方,也是极度克制的
基本就是 JDBC、reids、数据库连接池、json、文件上传这些基本功能有一个 provided 非强制依赖
多引入一个第三方,就多一个潜在风险
你再回看一下 spring boot 的引入的大量第三方,是不是细思极恐
spring boot 官方给出的一个啥正事也没干的 demo 居然需要 33 个 jar 包依赖,19 M 的体积,如果要添加 AOP、ORM、Template Engine 等常用功能,jar 量还将大量增加:
https://www.oschina.net/news/107259/jfinal-4-2-released
2019-08-30 10:21
@水利万物而不争 因为 jfinal 的 redis 插件仅仅是个极薄封装,连方法名都与底层的 jedis 是一样的,在源码中给出来了如何查看最全的文档:
/**
* Cache.
* Cache api 添加了中文注释,便于工程师更方便使用,另外还原样保持了
* Jedis api 的方法名称及使用方法,以便于仅仅通过查看 Redis 文档
* 即可快速掌握使用方法
* Redis 命令参考: http://redisdoc.com/
*/
上面的注释来自于:com.jfinal.plugin.redis.Cache.java
为了尽可能减少学习成本, jfinal 依照底层的 redis 原有的方法名、参数来安排 API, 只要原先会用 redis,直接使用 jfinal redis 插件根本不需要学习