我正在开发一个接受文件上传的页面.从理论上讲,我可以检测到他们发送给我的文件太大(通过查看其响应的Content-Length),并拒绝接受上传,返回HTTP 413"Request Entity Too Large"错误.
但是,似乎只是这样做是不够的 - 至少Firefox会在显示我的错误页面之前继续发送文件的其余部分(可能需要很长时间).
在HTTP规范说我:"可以关闭连接以防止客户持续的请求." 然而,做一个'close STDIN','shutdown STDIN,0',或者某些变种似乎没有办法 - Firefox仍然会继续发送文件.
我怀疑,当我的mod_perl处理程序关闭连接时,它只是关闭它自己和Apache之间的连接; Apache保持它与客户端之间的连接.有没有办法告诉Apache关闭连接？否则,这似乎是一个伟大的DoS向量.
欢迎大家提出意见.
我有一个Web应用程序,我一直在慢慢地从iBATIS 2迁移到使用Spring Data的JPA.
在大多数情况下,事情进展顺利,我一次只为一个域对象迁移DAO.但是,最近引起我注意的一个问题是在网站的某些部分显示过时的结果列表.
例如,我有一个"票证"部分,它显示了打开的票证列表,并允许您在不同的页面上查看特定票证.当我创建新票证时,我可以正确地在其特定页面上查看该票证.但是,打开的票证列表似乎在一段时间之后才会显示此新票证.
我试图排除的事情:
cacheModelsEnabled="false"在iBATIS配置中设置,我也会看到这个问题.<cacheModel>元素和cacheModel="x"属性,我也会看到这个问题.我也试图用iBATIS排除某种奇怪的事务状态,但似乎根本没有在这里使用任何事务.
我错过了什么？还有什么我应该试图解决这个问题吗？或者,我是否应该优先使用Spring Data JPA替换iBATIS层,这似乎不受此问题的影响？
UPDATE
我现在已经经历了很多我最近的变化git bisect,并且我已经将它缩小到引入Spring的变化org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.
因此,似乎某些交易的寿命比应有的长.我将添加更多日志记录,看看我是否可以确认这一点,然后寻找避免使用该过滤器的方法.
我有一个单一的Java应用程序,围绕@Service我的业务服务层的Spring bean 构建.通常,我的每个业务服务方法都有Spring Security注释(例如@PreAuthorize)来为该操作强制执行适当的授权规则.
在主Web应用程序流程中,这非常有效; 每个Web请求隐式地具有由会话cookie等处理的认证.
但是,当涉及到与其他"内部"系统的各种集成点时,我没有看到清晰的解决方案.
例如,我将从JMS队列中消耗方法,该队列已经在代理中定义了自己的身份验证和授权规则,因此我想隐含地"信任"我得到的消息.但是,就像现在的情况一样,一个简单的Camel路线如下:
WidgetService widgetService = lookup(WidgetService.class);
from("activemq:newWidget")
.unmarshall(...)
.bean(widgetService, "newWidget");
最后扔了一个AuthenticationCredentialsNotFoundException.
这告诉我Camel正在正确地调用我的bean,并且从Spring应用了所有神奇的AOP.
对于其他类似的事情,我已经围绕系统的入口点(例如,围绕Quartz Job的execute方法)应用AOP建议,这注入了一个PreAuthenticatedAuthenticationToken,但我不确定这是否真的是最好的方法.
我是否应该继续在建议中包含这些"可信"入口点以添加身份验证上下文,或者我是否应该更改我的服务层以使某些业务方法的特殊形式不需要身份验证,并确保我明确记录他们不是用于网络@Controller方法等？
我有一对实体,称它们为"Ticket"和"TicketComment".
门票有这个属性:
@OneToMany(mappedBy="ticket", cascade = CascadeType.ALL)
@OrderBy("date")
private List<TicketComment> comments = new ArrayList<>();
而且,TicketComment有这个:
@ManyToOne
@JoinColumn(name="TKT_ID")
@NotNull
private Ticket ticket;
我想,我正在使用的代码应添加一条新评论.但是,它似乎将新注释添加到数据库两次:
Ticket ticket = ticketRepo.findOne(id);
TicketComment newComment = new TicketComment();
// ...
newComment.setTicket(ticket);
ticket.getComments().add(newComment);
ticketRepo.save(ticket);
我想在没有重复的子实体之前,我已经能够成功地与类似的实体做到这一点......我可能会缺少什么？
更新:解决方法似乎是:
ticketRepo.newComment.setTicket(ticket);)链接,并用a保存ticketCommentRepo.因此,有两个不同的保存,一个应该只影响父节点,另一个应该只影响子节点.
我想把它归结为一次保存,但我不确定是否可能？
更新2:澄清观察到的症状.
如果我尝试简单地保存我的父"Ticket"实体并添加新的"TicketComment",会发生什么情况,我看到在数据库中创建了两个不同的记录,具有不同的主键,但具有相同的注释文本,相同或接近所以,时间戳.
所以,例如,假设我发表了一个评论,如"看起来不错".即使我在调试器中确认在ticket.getComments()我再次加载票证的详细信息页面后,我的...中只显示了一个"看起来不错" ,我看到类似的内容:
me @ 2015-09-11 23:16:58:看起来不错
me @ 2015-09-11 23:16:59:看起来不错
当我查看正在准备的SQL语句的一些调试日志时,我看到为我的TicketComments表调用两个相同的INSERT语句,然后是我的Tickets表的单个UPDATE ...
我的应用程序中有一些复杂的访问限制，基本上需要查看用户角色的组合以及域对象的某些深层属性才能做出访问决定。
对于我的某些方法（特别是诸如getItem(Integer id)和updateItem(Integer id, FormBean form)），我真的无法提前知道是否允许他们访问该项目，因为我还没有，所以我一直在使用@PostAuthorize。
但是，后一个示例updateItem(id, form)提出了挑战。我只想允许他们在某些特定情况下更新表单。现在，我确实看到@PostAuthorize导致他们执行不应该执行的操作时获得HTTP 403响应的原因，但是数据库更改没有回滚。
在这种情况下@PreAuthorize，是否有可能获得，@Transactional并且@PostAuthorize所有人都能很好地比赛？（我认为也许可以通过调整一些建议的顺序...但是我对如何完成该顺序尚不完全清楚）。
或者，我的系统是否变得足够复杂，以至于我真的不应该对Domain ACL感兴趣？不幸的是，关于这些的文档感觉很薄……