前言
磁盘怎么又满了?赶快 快 打电话给运维扩容扩容扩容!这个问题已经是我入职新公司两个月来,第 3 次听到了。经由一通领会,事情原来是这样的。虽然我们使用了阿里云的 OSS 工具存储服务,然则为了不露出 AccessKeyId 以及 AccessKeySecret 给客户端,以是全部是由客户端上传到我们的服务器,由我们服务器中转上传,实在只要上传完成删除响应的文件应该就不会引发磁盘空间不足的问题,怎样之前的精神小伙并没有干这一步,文件放磁盘受骗备份用。由此引发思索中转上传是不是太麻烦了,直传 OSS 不香吗? 若何保证 AccessKeyId 以及 AccessKeySecret 的平安以及 Bucket 权限问题呢?这就是下面要讲的阿里云 OSS 上的 Sts 授权模式。
STS 暂且授权接见 OSS
OSS 可以通过阿里云 STS(Security Token Service)举行暂且授权接见。通过 STS,您可以为第三方应用或子用户(即用户身份由您自己治理的用户)发表一个自定义时效和权限的接见凭证。
以上是官方原话,经由我的实践连系理论,可以得出:我们可以通过 STS 发表一个暂且的 AccessKeyId
,AccessKeySecret
,SecurityToken
, 用户可以通过这3个接见凭证对 Oss 举行响应操作。在我们申请颁布接见凭证的时刻,还可以设置对应的权限。
java基础(二)–main方法讲解
Coding
在使用下面测试前,请先完成 STS暂且授权接见OSS 的设置
- 安装 Nuget
dotnet add package aliyun-net-sdk-core
dotnet add package aliyun-net-sdk-sts
dotnet add package Aliyun.OSS.SDK.NetCore
- 代码参考案例
class Program
{
static void Main(string[] args)
{
var bucketName = "<your bucket>";
var accessKeyId = "<your accessKeyId>";
var accessKeySecret = "<your accessKeySecret>";
var endpoint = "<your endpint>";
var region = "<your region>";
var roleArn = "<your roleArn>"; // 通过阿里云RAM治理角色治理可以拿到
var roleSessionName = "xxx"; // 随机指定一个即可
var objectName = "test.txt";
IClientProfile profile =
DefaultProfile.GetProfile(region, accessKeyId, accessKeySecret);
DefaultAcsClient client = new DefaultAcsClient(profile);
AssumeRoleRequest request = new AssumeRoleRequest();
request.AcceptFormat = FormatType.JSON;
//指定角色ARN
request.RoleArn = roleArn;
request.RoleSessionName = roleSessionName;
request.DurationSeconds = 3600;
request.Policy = BuildPolicy(bucketName, "avatars"); // 设置对应的权限
AssumeRoleResponse response = client.GetAcsResponse(request);
Console.WriteLine("AccessKeyId: " + response.Credentials.AccessKeyId);
Console.WriteLine("AccessKeySecret: " + response.Credentials.AccessKeySecret);
Console.WriteLine("SecurityToken: " + response.Credentials.SecurityToken);
Console.WriteLine("Expiration: " + DateTime.Parse(response.Credentials.Expiration).ToLocalTime());
var ossClient = new OssClient(endpoint, response.Credentials.AccessKeyId,
response.Credentials.AccessKeySecret,
response.Credentials.SecurityToken);
try
{
byte[] binaryData = Encoding.ASCII.GetBytes("test");
MemoryStream requestContent = new MemoryStream(binaryData);
// 上传文件。
ossClient.PutObject(bucketName, $"{bucketName}/{objectName}", requestContent);
Console.WriteLine("Put object succeeded");
}
catch (Exception ex)
{
Console.WriteLine("Put object failed, {0}", ex.Message);
}
}
public static string BuildPolicy(string bucket, string dir)
{
return "{\n" +
" \"Version\": \"1\", \n" +
" \"Statement\": [\n" +
" {\n" +
" \"Action\": [\n" +
" \"oss:PutObject\"\n" +
" ], \n" +
" \"Resource\": [\n" +
$" \"acs:oss:*:*:{bucket}/{dir}/*\" \n" +
" ], \n" +
" \"Effect\": \"Allow\"\n" +
" }\n" +
" ]\n" +
"}";
}
}
可以修改 BuildPolicy
内里的 Json 动态设置,以上设置了客户端拿到接见凭证后,只能上传文件到指定目录,没有其他权限了。其次接见STS服务拿到的 AccessKeyId
与 AccessKeySecret
都是暂且与我们阿里云RAM控制面板拿到的是不一样的。这样就无须忧郁我们 AccessKeyId
与 AccessKeySecret
泄露以及接见权限的问题。
End
服务端发表授权凭证,客户端直传 OSS 应该是现在的最佳实践,后面再配合回调地址,可以更好的贴近现实场景。然则回调地址必须是公网可接见的,这里就没整了。直传 OSS 比之前中转节省时间,也不需要占用分外的服务器资源。
- 原文地址:链接 本文收录在小我私家博客 https://gridea.run,欢迎来踩
原创文章,作者:28x29新闻网,如若转载,请注明出处:https://www.28x29.com/archives/24948.html