1.本技术涉及邮件文件传输技术领域,尤其涉及一种邮件附件传输方法、系统、用户端和服务器端。
背景技术:
2.在当今互联网环境下,信息安全问题,尤其是企业信息安全问题日益突出,电子邮件系统作为一种在企业中被广泛应用的信息传递工具,其安全性应受到格外的重视。
3.邮件领域中对于超大附件的传输,标准协议是将超大附件上传至服务器端,并将其下载地址url嵌在邮件正文内容部分发送,收件邮箱通过url从服务器端下载附件,收件服务器端识别url下载地址展示给用户进行远端下载。大附件通过url获取,大附件通过固定url下载,url在原服务器端生成之后不变,只要定位的附件存在,其本身隐藏着数据暴露风险:该下载地址url可以直接被复制,并在任何有网络资源的地方进行下载。
技术实现要素:
4.为解决上述现有技术所存在的问题,本发明提出了一种邮件附件传输方法、系统、用户端和服务器端,能够提升邮件附件传输安全性。
5.本发明一方面提出一种邮件附件传输方法,包括:
6.接收随机码获取请求,所述随机码获取请求包括邮件唯一会话id和附件摘要;
7.验证本地是否存在所述附件摘要,若存在,则生成随机码并将所述随机码返回,若不存在,则拒绝所述随机码获取请求;
8.根据所述邮件唯一会话id、所述附件摘要和所述随机码生成附件的存放路径及对应的统一资源定位器url;
9.当接收到包含所述统一资源定位器url的下载请求时,返回所述附件。
10.进一步,在返回所述附件并传输结束后,清理本次生成的所述统一资源定位器url。
11.进一步,所述邮件唯一会话id包括邮件uid。
12.本发明还提出一种服务器端,包括:
13.第一接收模块,用于接收随机码获取请求,所述随机码获取请求包括邮件唯一会话id和附件摘要;
14.随机码生成模块,用于验证本地是否存在所述附件摘要,若存在,则生成随机码并将所述随机码返回,若不存在,则拒绝所述随机码获取请求;
15.第一url生成模块,用于根据所述邮件唯一会话id、所述附件摘要和所述随机码生成附件的存放路径及对应的统一资源定位器url;
16.传输模块,用于当接收到包含所述统一资源定位器url的下载请求时,返回所述附件。
17.进一步,还包括:
18.清理模块,用于在返回所述附件并传输结束后,清理本次生成的所述统一资源定位器url。
19.本发明还提出一种用户端,包括:
20.第一发送模块,用于向服务器端发送随机码获取请求,所述随机码获取请求包括邮件唯一会话id和附件摘要;
21.第二接收模块,用于接收服务器端返回的随机码或接收拒绝所述随机码获取请求的响应信息;
22.第二url生成模块,用于根据所述邮件唯一会话id、所述附件摘要和所述随机码生成统一资源定位器url;
23.附件下载模块,用于向服务器端发送附件下载请求,所述附件下载请求通过所述统一资源定位器url发起;
24.第三接收模块,用于接收服务器端返回的附件。
25.进一步,还包括:
26.会话结束通知模块,用于在附件接收完毕后,向服务器端发送本次会话结束信息,通知服务器端清理本次生成的所述统一资源定位器url。
27.本发明还提出一种邮件附件传输系统,包括如上所述的服务器端和用户端。
28.本发明的技术方案的有益效果:
29.本发明提出的一种邮件附件传输方法、系统、用户端和服务器端,通过在每次请求下载附件尤其是大附件时,在服务器端生成随机码,在用户端和服务器端用相同的算法生成统一资源定位器url,然后再进行下载。服务器端验证邮件唯一会话id和附件摘要后才发送随机码给用户端,只有用户端同时拥有邮件唯一会话id、附件摘要、随机码以及将这些信息生成统一资源定位器url的与服务器端相同的算法才能够获取实时统一资源定位器url进行下载附件,即使邮件明文被网络其他用户获取也无法获取实时统一资源定位器url进行下载,提高附件传输的安全性。
附图说明
30.为了更清楚地表达说明本发明实施例的技术方案,下面将对实施例描述所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
31.图1为本发明实施例邮件附件传输方法的交互实现示意图;
32.图2为本发明实施例服务器端的模块框图;
33.图3为本发明实施例用户端的模块框图。
具体实施方式
34.为了使本技术领域的人员更好地理解本技术方案,下面将结合本技术实施例中的附图,对本技术实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅是本技术一部分实施例,而不是全部的实施例。基于本技术中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本技术保护的范围。
35.下面详细描述本发明的实施例,实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,旨在用于解释本发明,而不能理解为对本发明的限制。
36.在本技术中,涉及的术语如下:
37.邮件uid:每封邮件的唯一编号,通过邮件相关协议获取。
38.url:统一资源定位器,这里指获取大附件数据的网络地址。
39.参见图1,本发明实施例的一种邮件附件传输方法,适用于邮件附件尤其是大附件传输时使用,基于用户端2和服务器端1实现,具体包括以下步骤:
40.服务器端1接收用户端2发送的随机码获取请求,随机码获取请求包括邮件唯一会话id和附件摘要,会话id包括每封邮件的唯一编号,通过邮件相关协议获取,通过邮件唯一会话id验证请求发起者是否为邮件接收者,增强用户端2安全。附件摘要为根据附件内容通过算法函数生成,例如可以通过hash函数,生成附件摘要digest。
41.服务器端1验证本地是否存在附件摘要,若存在,则生成随机码并将随机码返回,若不存在,则拒绝随机码获取请求。在另一个实施例中,服务器端1还同时验证邮件唯一会话id是否存在,在邮件唯一会话id和附件摘要同时在服务器端1中存在时才生成随机码并将随机码返回。
42.根据邮件唯一会话id、附件摘要和随机码生成附件的存放路径及对应的统一资源定位器url,通过统一资源定位器url可以从对应路径下载附件。生成统一资源定位器url分别在服务器端1和用户端2分别采用相同的算法根据邮件唯一会话id、附件摘要和随机码生成,生成算法预先内置于服务器端1和用户端2,这样,即使其他网络用户获取了邮件唯一会话id、附件摘要和随机码,没有内置算法也无法生成统一资源定位器url,也无法获取附件,提高附件安全性。
43.当接收到包含统一资源定位器url的下载请求时,返回附件。在用户端2通过点击url就可以从服务器下载附件。
44.作为上述实施例的进一步改进,在返回附件并传输结束后,清理本次生成的统一资源定位器url。具体地,在传输完成后,向服务器端1发送本次会话结束信息,结束信息如会话结束编号、结束通知等,通知服务器端1清理本次生成的统一资源定位器url。下一次下载附件时需要重新发起请求,再次生成随机码和统一资源定位器url,实现url动态生成,每次下载大附件请求对应下载地址不同,非固定url可直接被复制的,在本次传输完成后就清理掉本次url,即使本次url被其他网络用户获取也不能从服务器下载附件,提高附件安全性能。
45.在一个具体实施例中,邮件唯一会话id包括邮件uid,邮件uid是每封邮件的唯一编号,通过邮件相关协议获取,可增强用户端2安全。
46.本发明实施例的一种邮件附件传输方法,通过在每次请求下载附件尤其是大附件时,在服务器端1生成随机码,在用户端2和服务器端1用相同的算法生成统一资源定位器url,然后再进行下载。服务器端1验证邮件唯一会话id和附件摘要后才发送随机码给用户端2,只有用户端2同时拥有邮件唯一会话id、附件摘要、随机码以及将这些信息生成统一资源定位器url的与服务器端1相同的算法才能够获取实时统一资源定位器url进行下载附件,即使邮件明文被网络其他用户获取也无法获取实时统一资源定位器url进行下载,提高
附件传输的安全性能。而现有技术中,大附件数据通过固定url下载,url在原服务器生成之后不变,只要定位的附件数据存在,其本身隐藏着数据暴露风险,本发明实施例很好地解决了这个问题,本发明大附件下载交互经过用户端2和服务器的三次握手,采用随机码及邮件唯一会话id和附件摘要动态生成url的方式,每次下载大附件请求对应下载地址不同,非固定url可直接被复制的,在本次传输完成后就清理掉本次url,即使本次url被其他网络用户获取也不能从服务器下载附件,提高附件安全性。
47.参见图2,本发明实施例还提出一种服务器端1,包括:
48.第一接收模块11,用于接收随机码获取请求,随机码获取请求包括邮件唯一会话id和附件摘要;
49.随机码生成模块12,用于验证本地是否存在附件摘要,若存在,则生成随机码并将随机码返回,若不存在,则拒绝随机码获取请求;
50.第一url生成模块13,用于根据邮件唯一会话id、附件摘要和随机码生成附件的存放路径及对应的统一资源定位器url;
51.传输模块14,用于当接收到包含统一资源定位器url的下载请求时,返回附件。
52.进一步,还包括:
53.清理模块15,用于在返回附件并传输结束后,清理本次生成的统一资源定位器url。
54.参见图3,本发明实施例还提出一种用户端2,包括:
55.第一发送模块21,用于向服务器端1发送随机码获取请求,随机码获取请求包括邮件唯一会话id和附件摘要;
56.第二接收模块22,用于接收服务器端1返回的随机码或接收拒绝随机码获取请求的响应信息;
57.第二url生成模块23,用于根据邮件唯一会话id、附件摘要和随机码生成统一资源定位器url;
58.附件下载模块24,用于向服务器端1发送附件下载请求,附件下载请求通过统一资源定位器url发起;
59.第三接收模块25,用于接收服务器端1返回的附件。
60.进一步,还包括:
61.会话结束通知模块26,用于在附件接收完毕后,向服务器端1发送本次会话结束信息,通知服务器端1清理本次生成的统一资源定位器url。
62.本发明还提出一种邮件附件传输系统,包括上述的服务器端1和用户端2。
63.本发明实施例的服务器端1、用户端2以及邮件附件传输系统的工作原理和上述方法相同,在此不做赘述。
64.应该明白,公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好,应该理解,过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素,并不是要限于所述的特定顺序或层次。
65.本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其它实施例的不同之处,各个实施例之间相同或相似部分互相参见即可。
66.专业人员还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本技术的范围。
67.结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。
68.为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的,但是本领域普通技术人员应该认识到,各个实施例可以做进一步的组合和排列。因此,本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。
转载请注明原文地址:https://tc.8miu.com/read-360.html