I am using WebDav to copy and paste multiple files into Alfresco.
The problem is that I can only do this with administrator IDs.
When I try to create new files or update existing files as a non-administrator
user, I get the following error:
HTTP Status Code: 403 caused by: org.alfresco.repo.security.permissions.AccessDeniedException: 03300303 Access Denied. You do not have the appropriate permissions to perform this operation.
Is there anyway to allow non-administrator IDs to create/update files?
The Alfresco WebDAV support uses identical permissions to the rest of Alfresco. Nothing special - it's just one of the number of different ways you can interact with the nodes stored in your Alfresco repo.
As such, the user you log in as needs to have both read and write permissions to the folder in question. Typically, that means they need to be a member of the site you want to write to, and need to have permissions higher than Consumer.
As long as the user has write permissions to where you want to write to, they'll be able to make changes using WebDAV.
Related
I have noticed that in Dropbox, you can share a file with another user, in 'read' mode, and that viewer has the ability to share that file with others via a read-only sharable link. However, in Drive, a read-only user is unable to share a link with another user at all.
Which approach would be more similar to how the Unix/Linux approach to permissions works? Why?
Try to visit the Google Drive REST API Overview in the official GDrive documentation specifically in the Share and collaborate section which was elaborated as:
apps can display a standard Google Drive sharing dialog to let users share files
What you want to do is more on Manage Sharing:
Access to files & folders is determined by an access control list
(ACL). An ACL is a list of permissions that determine whether or not
users can perform actions on a file such as read or write. See the
permissions
guide
for additional details about permissions and roles along with the
reference
guide.
Also, what want is to assign a direct file permission to the user, group or domain. It was stated to use the teamDrivePermissionDetails field to determine the use of effective role.
To see more on how to lists a file's or Team Drive permission, you can refer to the method Permissions: list
I want to prevent my Alfresco 5.1 users from uploading anything else than ".pdf" and ".xslx" files.
What is the best way to implement that in Alfresco?
Is there a setting, or do I have to write some Java code?
Filtering must be done on the file extension, regardless of MIME types. The restriction must apply via FTP too.
You can't do this through simple Alfresco configuration. I'd suggest writing a Behaviour that would implement this logic. It will get triggered no matter how something ends up in Alfresco (Share, FTP, custom application, etc).
http://docs.alfresco.com/5.2/references/dev-extension-points-behaviors.html
You can not restrict throught FTP. Some ftp client provide file name filter facility,Using that you can Restrict.In alfresco try to create rule ,on that rule execute script ,that script contain code to delete file which is not allow.
I am building a notes functionality with attachments in it, I have been using Meteor Uploads for file uploading. Everything works fine except for permissions. I have searched almost everything related to this but somehow I can not find a full example neither a clear answer.
There is an event shown below which is supposed to handle permission checks, but this does not run in fibre, so you have no access to collections and UserId
validateRequest: function (req, resp) {
}
There are two issues I am trying to solve:
Allow only the users that have permission to post notes, to be able to upload files.
A way to provide more secure file accessing
The first one would not exist as an issue if there was a way to call file start upload in server(As far as I know/tried it is only called in client).
Uploader.startUpload.call(Template.instance(), e);
I have made some security checks before uploading file(calling a server method) but that is in client. I have also added a cookie after opening the page which I then validate in server in order to make files not accessible out of app.
I have also read that permissions can be achieved by using tokens/secret keys as mentioned here but could not find a proper example.
PLEASE NOTE
Maybe the first issue is not a real issue in my scenario because I have permission checks when showing Note post ability but I wanted to know what is a good approach I could take.
Most important issue I believe is the second one regarding file access, what is a proper way to serve files based on User permission? Also a good way to encrypt uploading file's name so that users do not access files by guessing the file name might be helpful.
Thank you guys!
I need very advanced and effective method of Preventing Users from Downloading file from website directly in asp.net.
Method should -
limit downloads,
limit time,
limit requests,
etc.
but should be downloadable by active login users
Delete the file from the server.
Any user trying to download it will not longer succeed.
You can put your files into a directory and configure that directory as not accessible by public users.
Store the files in a folder which is not accessible via IIS (i.e., not underneath your web application's root)
Create an .ashx generic handler which takes a file identifier (either filename, or ID of some sort) as a QueryString parameter.
In that .ashx, perform whatever checks you want to perform: is the user logged in? have they downloaded too many files? etc.
Then, if you decide that they should be allowed to download it, set the response headers appropriately and write the file out to Response.OutputStream
What would be the best method to implement the following scenario:
The web site calls for a image gallery that has both private and public images to be stored. I've heard that you can either store them in a file hierarchy or a database. In a file hierarchy setup how would prevent direct access to the image. In a database setup access to the images would only be possible via the web page view. What would be a effective solution to pursue?
[Edit] Thanks all for the responses. I decided that the database route is the best option for this application since I do not have direct access to the server. Confined to a webroot folder. All the responses were most appreciated.
Having used both methods I'd say go with the database. If you store them on the filestore and they need protecting then you'd have to store them outside the web-root and then use a handler (like John mentions) to retrieve them, anyway. It's as easy to write a handler to stream them direct from database and you get a few advantages:
With database you don't need to worry about filestore permissions or generating unique filenames or folder hierarchies etc.
With database you can easily apply permissions and protection directly - no trying to work out who can view what based on paths etc.
With a database you can store the image and metadata all together - when you delete the metadata you delete the image - no possibility of orphaned records where you delete from database but not from filestore
Easier to back-up database and images and then restore
The disadvantage is that of performance, but you can use caching etc. to help with that. You can also use FILESTREAM storeage in SQL Server 2008 (and 05?) which means you get filesystem performance but via the DB:
"FILESTREAM integrates the SQL Server
Database Engine with an NTFS file
system by storing varbinary(max)
binary large object (BLOB) data as
files on the file system. Transact-SQL
statements can insert, update, query,
search, and back up FILESTREAM data.
Win32 file system interfaces provide
streaming access to the data.
FILESTREAM uses the NT system cache
for caching file data. This helps
reduce any effect that FILESTREAM data
might have on Database Engine
performance. The SQL Server buffer
pool is not used; therefore, this
memory is available for query
processing."
Using file hierarchy, you can put the files out of the website file folder, for example, suppose the web folder is c:/inetpub/wwwroot/somesite, put the file under c:/images/, so that the web users won't be able to access the image files. but you cannot use the direct link in your website neither, you need to create some procedure to read the file, return the stream.
personally I think it's better to put the file in the database, still create some procedure to retrieve the binary image data and return to wherever it needed.
In reality both scenarios are very similar, so it's up to you... Databases weren't designed to serve files, but if the size isn't really a concern for you, I don't see a problem with doing it.
To answer your question about direct access, you'd setup the file images the same way you would for the database: You'd use some sort of page (probably a .ashx handler) that serves the images, allowing you a layer of logic between the user and image to determine whether or not they should have access to it. The actual directory the images are located in would then need to either a) not be part of the directory structure in IIS or b) if it is part of IIS, only allow windows authenticated access, and only allow the account the application process is running under access to the directory.
If you're using IIS7, since .net jumps in the pipeline early I believe you can protect jpg files as well, just by using a role manager and applying roles to file system folders. If you're using IIS6, I've done something similar to the answer by John, where I store the actual file outside of the wwwroot, and use a handler to decide if the user has the correct credentials to view the image.
I would avoid the database unless you have a strong reason to do this - and I don't think a photo gallery is one of them.
Neither. Amazon S3 offers a very simple API for accepting uploads. You can use SimpleDB or your SQL database to track the URLs and permissions. Set the entire S3 bucket to private, and authenticate to it using your AWS key on the ASP.NET server.
Very little code is required to upload to S3, and very little more would be required to perform bookeeping in SQL.
Once they're in S3, grab the image resizer library and the S3 Reader plugin and you can have your entire system running in under an hour. And - it will scale properly. No disk or database space limits. Ever.
You can implement authorization using the AuthorizeImage event of the Image Resizer library. Just throw an AccessDeniedException if access isn't allowed for the current user.
If you want to tune performance a bit mare, add both the DiskCache and CloudFront plugins. CloudFront can edge-cache the public images (inexpensively), and DiskCache will handle the private images, serving them at static-file speeds.