-
Notifications
You must be signed in to change notification settings - Fork 7
Scenarios Definition
The Tag concept is quite popular in modern applications now days. Since release 0.3, the Tag concept was enabled from bottom to up.
- When uploading photos, it is allow user to enter Tag;
- Tag Cloud page shows the amount of the count per Tag; (There is no navigation support from Tag Cloud yet);
- Tag can be used for searching;
Since release 0.3, during uploading photo, the server will extract the EXIF for the following attributes:
- Camera Maker;
- Camera Model;
- Lens Model;
- Aperture;
- Shutter Speed;
- ISO;
All those attributes are stored for Photo and enabled for searching;
A powerful Searching functionality was provided to search photos; The searching supports the attribute list and tag mentioned above;
The anonymous user stands for users which not logged in yet or failed to recognize.
The signed-in user stands for the users who have logged in successfully and with relevant role assigned.
Before version 0.3, the authority definition are controlled by roles and claims.
There are two roles defined
- Gallery Admin.
- Gallery Pro.
The claims defined within the roles as following:
- GalleryAlbumCreate. String based value, allowed value: All, OnlyOwner;
- GalleryAlbumChange. String based value, allowed value: All, OnlyOwner;
- GalleryAlbumDelete. String based value, allowed value: All, OnlyOwner;
- GalleryNonPublicAlbumRead. String based value, allowed value: All, OnlyOwner;
- GalleryPhotoUpload. String based value, allowed value: All, OnlyOwner;
- GalleryPhotoDelete. String based value, allowed value: All, OnlyOwner;
- GalleryPhotoChange. String based value, allowed value: All, OnlyOwner;
- GalleryPhotoUploadSize. String based value, allowed format: minSize-maxSize;
Since release 0.3, the storage of authority control has moved to the API layer instead of the ID service.
There is new introduced table storing the user detail information, including:
- AlbumCreate. Boolean. Indicates current user can create an album or not;
- AlbumChange. TinyInt value. Indicates current user can change an album or not. 1 stands for All, 2 stands for OnlyOwner, NULL stands for no authority;
- AlbumDelete. TinyInt value. Indicates current user can delete an album or not. 1 stands for All, 2 stands for OnlyOwner, NULL stands for no authority;
- PhotoUpload. Boolean. Indicates current user can upload photo(s) or not;
- PhotoChange. TinyInt value. Indicates current user can change a photo or not. 1 stands for All, 2 stands for OnlyOwner, NULL stands for no authority;
- PhotoDelete. TinyInt value. Indicates current user can change a photo or not. 1 stands for All, 2 stands for OnlyOwner, NULL stands for no authority;
- UploadFileMinSize, Int value. The Minimum file size (in KB) of per upload photo. NULL stands for no authority;
- UploadFileMaxSize, Int value. The Maximum file size (in KB) of per upload photo. NULL stands for no authority;
- SystemAdmin. Boolean. Indicates that current user is an administrator user.
TBD.
Though sharing is the spirit of the internet, but the data protection is another key factor to sprinkle the colors of the world.
For data protection, along side with the authority control, non-public photo will be stored in Azure Storage account instead of the public folder.
For sharing, it allows the user to share the album only via the Access Code protection.
TBD.
Public album means the album can be viewed by anonymous users.
Non-public album can only be viewed by its creator.
It is quite a common case to share photo with you specified users only. In this case, asked all your clients to register their ID won't be a polite way, therefore, using an access code as a protection turns into an better solution: album is still public but only the anonymous users can take a look upon the photos inside.
You can change the access code to invalid the sharing.
The anonymous user can only fetch out the public albums.
The public albums only protected with access code can be fetched out either, but the first photo inside won't be returned;
Provide photo normally stands for searching out the album which contains that photo.
Although it shall rarely happened in real life (I cannot figure out an useful end user case for this yet), but symmetrically, it is supported.
Technically speak, it will perform a filter upon the results coming from Scenario 1.
Signed in user will fetch out not only the public albums but also his/her own albums;
In another word, the album's 'CreatedBy' will be used in comparison with current user's id.
Normally the end user case here is, assign the photo to albums. It requires to fetch out the assigned albums.
From codes' perspective, this scenario filtered out the output of Scenario 2.
This scenario actually mapping to 'Fetching photos for anonymous user with album id provided';
As it is described in Common part "Protected album with Access Code", the end user will be prompted with dialog to input the 'Access Code'. The photos within this album will be returned if and only if the access code is correct.
It won't happen because the non-public albums won't be fetched out.
Anyhow, if it is come real, an "unauthorized" page is the result.
The Signed-in user access his/her album despite of the 'access code' setting.
This scenario actually mapping to 'Fetching photos for signed-in user with album id provided';
The anonymous user cannot create an album. In UI part, it will leads to a 'prohibition' page.
In API part, it is protected by [Authorize] attributes with relevant policies or requirements.
The anonymous user cannot update an album. In UI part, it will leads to a 'prohibition' page.
An album can only be changed by its own creator or an user with "Gallery Admin" role. The other signed-in user will be led to an 'unauthorized' page.
In API part, it is protected by [Authorize] attributes with relevant policies or requirements.
The anonymous user cannot update an album. In UI part, it will leads to a 'prohibition' page.
An album can only be changed by its own creator or an user with "Gallery Admin" role. The other signed-in user will be led to an 'unauthorized' page.
In API part, it is protected by [Authorize] attributes with relevant policies or requirements.
The anonymous user cannot delete an album. In UI part, it will leads to a 'prohibition' page.
An album can only be removed by its own creator or an user with "Gallery Admin" role. The other signed-in user will be led to an 'unauthorized' page.
In API part, it is protected by [Authorize] attributes with relevant policies or requirements.
Public photo means the photo can be viewed by anonymous users.
Non-public photo stands for the photo which can only be viewed by its creator.
Public photos added to non-public album won't impact it's visibility, meaning the photos can also be viewed by the anonymous users.
Non-public photos added to public album will impact its visibility, meaning the photo can be viewed by the anonymous user during inspecting the album detail page but the photo can also cannot be fetched in photos page.
Public photos stored in 'uploads' folder.
Non-public photos will be stored in Azure storage photos or database.
Without an album provides, the anonymous user will fetch out all photos which is public.
It's a most frequently used case, because the web app go directly to Photo page when it launched. The routing of the web app marked the '/photos' as the default.
The anonymous user fetch out all photos within the specified album.
If the album is a non-public album, failure throw out. And the web app leads the user to "prohibited" page. It can happen if the user input the URL directly to a specified album;
If the album is a public album with access code's protection, the web app promotes the user input the access code. It can happen if the user input the URL directly t a specified album;
If the album is a public album without access code's protection, the photos will be fetched out and leads the user to the album detail page.
Without an album provides, the signed-in user will fetch out all public photos and all non-public public uploaded by himself/herself.
The signed-in user fetch out all photos within the specified album.
If the album is a non-public album and the album not owned by the current sign-in user, failure throw out. And the web app leads the user to "prohibited" page. It can happen if the user input the URL directly to a specified album;
If the album is a public album with access code's protection, the web app promotes the user input the access code. It can happen if the user input the URL directly t a specified album;
If the album is a public album without access code's protection or the album is a non-public album but created by the current user, the photos will be fetched out and leads the user to the album detail page.
For public photo, it is a URL of a static file.
For non-public photo, it will check the authority of the current user instead of returning the photo directly.
It's not allow anonymous user upload the photos directly to avoid any potential risks. The anonymous user cannot upload a photo, it will leads to a 'prohibition' page instead.
The signed-in user depends on their roles, the allowed size of uploaded size will be different.
The anonymous user cannot change the metadata of a photo, it will leads to a 'prohibition' page instead.
For sign-in user, the photo can only be deleted by its creator or an admin.
The anonymous user cannot upload a photo, it will leads to a 'prohibition' page instead.
For sign-in user, the photo can only be changed by its creator or an admin.
The anonymous user cannot delete a photo, it will leads to a 'prohibition' page instead.
For sign-in user, the photo can only be deleted by its creator or an admin.
- Created by Alva Chien, 2016.9.4
- Updated by Alva Chien, 2016.10.27 for correcting some terms.
- Updated by Alva Chien, 2018.6.20 for new features in Release 0.3.