Hello @trendline ,
Files that uploaded with File Management module can't be downloaded directly by a link for now. We've added "token validation" for extra security.
First, the UI makes a request to the backend application to take token, that token will be used for download, Example:
UI makes a request -> // api/file-management/get-token / [FILE-ID] Token = 12345 UI opens a new tab with the url -> api/file-management/[FILE-ID]?token=12345 Then the download process will start.
Tokens become expired when they used once. If you want to disable that, for each download request, you need to consume new token.
So, how you can achieve your request, let me show you one example.
You may create unique tokens for each dowload request by overriding DownloadAsync
method of FileDescriptorController
controller:
Note that, you need to secure your api yourself.
[HttpGet]
[Route("download/{id}")]
[AllowAnonymous]
public virtual async Task<IRemoteStreamContent> DownloadAsync(Guid id, string token)
{
var fileDescriptor = await FileDescriptorAppService.GetAsync(id);
// add this
if(string.IsNullOrWhiteSpace(token))
{
token = await FileDescriptorAppService.GetDownloadTokenAsync(id);
}
Response.Headers.Add("Content-Disposition", $"attachment;filename=\"{fileDescriptor.Name}\"");
Response.Headers.Add("Accept-Ranges", "bytes");
Response.ContentType = fileDescriptor.MimeType;
return await FileDescriptorAppService.DownloadAsync(id, token);
}
Hi,
I successfully set culture by using Accept-Language
header and get response with defined culture.
Note: When ABP could not find the given culture files, it roll-backs to default culture and responses with default culture.
Please make sure you've successfully added new language to your application.
https://docs.abp.io/en/abp/latest/Localization
Hello @uyarbtrlp
Yes, I've reproduced that strange problem.
It looks like we have missing configuration related with identity claims in our module-pro
template.
This is only development time problem of course, when you test it with normal application it will work without problem. (not host appilations in your module solution)
Thanks for your feedback, we will investigate and fix the problem. Will reply here again with the fix.
As I mentioned before;
ABP module & module-pro templates do not have any initial Feature implementation like "Enable/Disable"
But all ABP and Commercial ABP prebuilt modules (like Forms
and others) have their own feature implementation, at least "Enable/Disable", those features added by Volo and ABP team while developing the module.
When you are creating a new module, ABP Suite uses module-pro
template and the template does not have any feature implementation.
So, when you create a new module, you must add feature to your module by yourself for now. You can easily add any feature by following documentations below:
https://docs.abp.io/en/abp/latest/Features https://docs.abp.io/en/abp/latest/Modules/Feature-Management
For the second question:
If you want to add a script to layout, you can use Hook
system. Please check the documentation below.
https://docs.abp.io/en/abp/latest/UI/AspNetCore/Layout-Hooks
Hello @Spospisil ,
Thanks for your feedback, we will fix this problem asap.
Credit refunded.
Hello @yasin.hallak.89
ABP module & module-pro templates do not have any initial Feature
implementation like "Enable/Disable"
If you want to add feature to your module and manage it by last application, please follow the documentation below:
https://docs.abp.io/en/abp/latest/Features https://docs.abp.io/en/abp/latest/Modules/Feature-Management
Also, we will discuss to add "enable-disable" feature to our module templates.
Actually, it depends for your application development.
All ABP Framework modules have IHasConcurrencyStamp
implementation for their update dtos.
But easyCrm application and suite templates does not.
For every situation, I always suggest to use IHasConcurrencyStamp
for update dtos to prevent future problems, because on low traffic, concurrency problem might not occur but under the high traffic, I believe it will :)
So, I will suggest to add IHasConcurrencyStamp
implementation by default to Suite team. They will discuss and work on it.
For now, if you want to make sure your app is stone like solid, please implement concurrency to your application :)
Hello @LW
Short answer; Yes, you should always cycle the concurrency stamp through client.
We always want to be sure that we are updating an entity what we get for updating.
Here is a gif that shows that an entity can be changed by another client while you are on updating.
To prevent that, we need to cycle the concurrency stamp. Because we must know which entity state is updating by client?
If this answer is not properly explains logic, please reply here :)
Hi,
Could you please check " The AppUser Entity & Custom Properties " section at following article.
https://community.abp.io/articles/unifying-dbcontexts-for-ef-core-removing-the-ef-core-migrations-project-nsyhrtna