Running the query :
https://graph.microsoft.com/v1.0/me/drive/root/search(q='File.txt')
It works in graph explorer, but when I try to run the same in console application with proper AuthProvider and Permissions, it is giving access denied error.
Used documentation : https://learn.microsoft.com/en-us/graph/api/driveitem-search?view=graph-rest-1.0&tabs=http
Gave all the App permissions ...
Is there any other way to check if a file is present in a library or not ?
Related
I am trying to convert an Excel document into PDF in a ASP.Net Web application using Pdftron (Pdfnet) library.
Following is my code for the above purpose.
pdf.PDF.PDFDoc newSalaryFitmentPdf = new pdf.PDF.PDFDoc();
pdftron.PDF.Convert.ToPdf(newSalaryFitmentPdf, newSalaryFitmentExcel.FullName);
salaryFitment = newSalaryFitmentPdf.Save(pdf.SDF.SDFDoc.SaveOptions.e_linearized);
But I am getting the following exception when the program is trying to execute the second line.
Exception:
Message: An error occurred while converting the file.
Detailed error:
Error creating a new Excel application instance.
Code: PDFTRON_UNKNOWN (-2147024891)
File: "Excel.cpp":51
Log:
Start check system account.
Session ID is: 0.
Failed to create Desktop folder in SystemProfile. boost::filesystem::create_directory: Access is denied: "C:\Windows\system32\config\systemprofile\Desktop"
Failed to create Desktop folder in SystemProfile. boost::filesystem::create_directory: Access is denied: "C:\Windows\SysWOW64\config\systemprofile\Desktop"
Done checking system account.
Creating an Excel application instance.
Conditional expression: false
Version : 6.7.1.61823N
Filename : Convert.cpp
Function : trn::PDF::Convert::ToPdf
Linenumber : 1692
Any help would be highly appreciated.
Failed to create Desktop folder in SystemProfile. boost::filesystem::create_directory: Access is denied: "C:\Windows\system32\config\systemprofile\Desktop"
Failed to create Desktop folder in SystemProfile. boost::filesystem::create_directory: Access is denied: "C:\Windows\SysWOW64\config\systemprofile\Desktop"
You must set your application to have read/write access to these directories. Please see this article for further information.
edI have C# ASP.NET 4.5 Webform application and use the following code:
if (!EventLog.SourceExists(sSource)) EventLog.CreateEventSource(sSource, sLog);
EventLog.WriteEntry(sSource, message, level);
Since the first line was failing I created
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\IDDISLOG in registry
I get the following exception on WriteEntry Method:
Cannot open log for source 'IDDISLOG'. You may not have write access.
Searched other similar questions but none worked for me.
Here is what I have done so far:
Added "Network service" to the project file folder
Added Network service to and gave it full access.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog
Added Nertwork service to and gave it full access.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Security
Checked and saw w3wp.exe *32 process runs with User Name ASP.Net v4.0.
So added ASP.Net v4.0 to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog
Still, error remains
Your user account may not have sufficient privileges to create an event source, which only administrator accounts can do. If you can log in as an administrator, either run your code again or add a folder here: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\IDDISLOG
That should allow your application to write to the event log with that source. You may need to configure the actual registry entry further to suit your needs.
In IIS (Windows server), you should change de identity used by de app pool, so the new identity has permission to write to the event log.
Select the app pool and advanced settings. then edit and insert a custom account, althoug local system will suffice. If you use a custom account be sure not to use a user whose password is going to expire, because when it happens logging to event log will fail.
I´m developing an app that is reading jpeg and pdf files from a configurable location on the filesystem.
Currently there is a running version implemented in WPF and now I´m trying to move to the new Windows Universal apps.
The following code works fine with WPF:
public IList<string> GetFilesByNumber(string path, string number)
{
if (string.IsNullOrWhiteSpace(path))
throw new ArgumentNullException(nameof(path));
if (string.IsNullOrWhiteSpace(number))
throw new ArgumentNullException(nameof(number));
if (!Directory.Exists(path))
throw new DirectoryNotFoundException(path);
var files = Directory.GetFiles(path, "*" + number + "*",
SearchOption.AllDirectories);
if (files == null || files.Length == 0)
return null;
return files;
}
With using Universal Apps I ran into some problems:
Directory.Exists is not available
How can I read from directories outside of my app storage?
To read from an other directory outside the app storage I tried the following:
StorageFolder folder = StorageFolder.GetFolderFromPathAsync("D:\\texts\\");
var fileTypeFilter = new string[] { ".pdf", ".jpg" };
QueryOptions queryOptions = new QueryOptions(CommonFileQuery.OrderBySearchRank, fileTypeFilter);
queryOptions.UserSearchFilter = "142";
StorageFileQueryResult queryResult = folder.CreateFileQueryWithOptions(queryOptions);
IReadOnlyList<StorageFile> files = queryResult.GetFilesAsync().GetResults();
The thing is: It isn´t working, but I get an exception:
An exception of type 'System.UnauthorizedAccessException' occurred in TextManager.Universal.DataAccess.dll but was not handled in user code
Additional information: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
I know that you have to configure some permissions in the manifest, but I can´t find one suitable for filesystem IO operations...
Did someone also have such problems/a possible solution?
Solution:
From the solutions that #Rico Suter gave me, I chosed the FutureAccessList in combination with the FolderPicker. It is also possible to access the entry with the Token after the program was restarted.
I can also recommend you the UX Guidlines and this Github sample.
Thank you very much!
In UWP apps, you can only access the following files and folders:
Directories which are declared in the manifest file (e.g. Documents, Pictures, Videos folder)
Directories and files which the user manually selected with the FileOpenPicker or FolderPicker
Files from the FutureAccessList or MostRecentlyUsedList
Files which are opened with a file extension association or via sharing
If you need access to all files in D:\, the user must manually pick the D:\ drive using the FolderPicker, then you have access to everything in this drive...
UPDATE:
Windows 10 build 17134 (2018 April Update, version 1803) added additional file system access capabilities for UWP apps:
Any UWP app (either a regular windowed app or a console app) that declares an AppExecutionAlias is now granted implicit access to the files and folders in the current working directory and downward, when it’s activated from a command line. The current working directory is from whatever file-system location the user chooses to execute your AppExecutionAlias.
The new broadFileSystemAccess capability grants apps the same access to the file system as the user who is currently running the app without file-picker style prompts. This access can be set in the manifest in the following manner:
xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
...
IgnorableNamespaces="uap mp uap5 rescap">
...
<Capabilities>
<rescap:Capability Name="broadFileSystemAccess" />
</Capabilities>
These changes and their intention are discussed at length in the MSDN Magazine article titled Universal Windows Platform - Closing UWP-Win32 Gaps. The articles notes the following:
If you declare any restricted capability, this triggers additional
scrutiny at the time you submit your package to the Store for
publication. ... You don’t need an AppExecutionAlias if you have this
capability. Because this is such a powerful feature, Microsoft will
grant the capability only if the app developer provides compelling
reasons for the request, a description of how this will be used, and
an explanation of how this benefits the user.
further:
If you declare the broadFileSystemAccess capability, you don’t need to
declare any of the more narrowly scoped file-system capabilities
(Documents, Pictures or Videos); indeed, an app must not declare both
broadFileSystemAccess and any of the other three file-system
capabilities.
finally:
Even after the app has been granted the capability, there’s also a
runtime check, because this constitutes a privacy concern for the
user. Just like other privacy issues, the app will trigger a
user-consent prompt on first use. If the user chooses to deny
permission, the app must be resilient to this.
The accepted answer is no longer complete. It is now possible to declare broadFileSystemAccess in the app manifest to arbitrarily read the file system.
The File Access Permissions page has details.
Note that the user can still revoke this permission via the settings app.
You can do it from UI in VS 2017.
Click on manifest file -> Capabilities -> Check photo library or whatever stuff you want.
According to MSDN doc : "The file picker allows an app to access files and folders, to attach files and folders, to open a file, and to save a file."
https://msdn.microsoft.com/en-us/library/windows/apps/hh465182.aspx
You can read a file using the filepicker through a standard user interface.
Regards
this is not true:
Files which are opened with a file extension association or via sharing
try it, by opening files from mail (outlook) or from the desktop...
it simply does not work
you first have to grant the rights by the file picker.
so this ist sh...
This is a restricted capability. Access is configurable in Settings > Privacy > File system. and enable acces for your app. Because users can grant or deny the permission any time in Settings, you should ensure that your app is resilient to those changes. If you find that your app does not have access, you may choose to prompt the user to change the setting by providing a link to the Windows 10 file system access and privacy article. Note that the user must close the app, toggle the setting, and restart the app. If they toggle the setting while the app is running, the platform will suspend your app so that you can save the state, then forcibly terminate the app in order to apply the new setting. In the April 2018 update, the default for the permission is On. In the October 2018 update, the default is Off.
More info
I have a problem with starting the Excel Application under a particular user.
I try to schedule this script (C#) through an application X (not Windows Task Scheduler. And this application will always use a service account to run services on the server). If I run the C# script in command prompt under the same user, it runs. Under the application X, which uses the exact same user, to initiate the C# script, it fails to open the Excel application (not sufficient permission?).
This script calls:
app.Workbooks.Open(ExcelFileName,0,false,Type.missing....), yet it gives the following error:
Microsoft Excel cannot access the file "...". There are several possible reasons:
-The file name or path does not exist.
-The file is being used by another program.
-The workbook you are trying to save has the same name as a currently open workbook.
I tried all the methods that I found online to no avail.
Create directory “C:\Windows\SysWOW64\config\systemprofile\Desktop” (for 64 bit Windows) or “C:\Windows\System32\config\systemprofile\Desktop” (for 32 bit Windows). Then Set full control permissions on Desktop directory above (for example in Win7 & IIS 7 & DefaultAppPool set permissions for user “IIS AppPool\DefaultAppPool”)
Changed the DCOM config for the Microsoft Excel application to include this user for Local/Remote Launch and Access
Enabled all macros in Excel and set the Trust Center.
Add the user to have full control on all folders that contain the Excel file.
Under DCOM config, Microsoft Excel Application, if I modify the Identity tab to check on "This User" and enter the username/password to let Excel always run under that user. Then the application runs perfectly. However, other users can't run the excel application on their own with the following error: "Cannot use object linking and embedding". If I check "Use the launching user", then Excel can't be launched. No errors in the logs or events anywhere to check.
Yet, still the same error. I think it's permission but I am not sure where and what to do for this to work.
Now, normally, when I run this excel report, I can double-click on the file and it'd automatically run, save the new parameters into the current file and generate a new excel file (with date attached to the file name). That means there is a change (save) to the original file.
I appreciate all your help!
I found the problem is the layer of security in the server!
Creating the Desktop folder inside the C:\Windows\System32\config\systemprofile and giving the service account permission to access the desktop folder is not enough.
I modified the C:\Windows\System32\config (or C:\windows\SysWOW64\config) folder to allow permission to the service account in security tab.
Then I also had to set up the same permission for the sub folder C:\Windows\System32\config\systemprofile (or C:\windows\SysWOW64\config\systemprofile) for the service account.
This works!
Microsoft Excel cannot access the file in Server 2012 Excel 2016.. checked various solutions online to create folder desktop in C:\Windows\SysWOW64\config\systemprofile\desktop.. didn't work for this but then i added a folder desktop in System32 and that definitely worked.
Since I have 64-bit Excel installed, the proper directory turned out to be the
c:\windows\system32\config\systemprofile\desktop
I ran across another way you can get this error: when you try to save a file with an "illegal" name, such as one with whacks (forward slashes) in it.
For that reason, it would seem reasonable that the err msg would give that as one possible explanation of the problem, but...no!
Specifically, I was trying to save a file named C:\RoboReporter\ABUELITOS\20160524_1327\ABUELITOS - Fill Rate - 4\1\61910B10
The whacks (shown as backwhacks in the copied exception text, but seen as forwardwhacks when hovering over the value when debugging) were the cause of the discombobulation. Once I fixed that by replacing whacks with underscores:
filename = String.Format("{0}\\{1} - Fill Rate - {2}.xlsx", uniqueFolder, _unit, _begDate.ToShortDateString());
filename = filename.Replace("/", "_");
...all went swimmingly.
i am trying to upload files in asp.net and putting a specific path to be saved. windows user.
it is outputting me an error :
System.UnauthorizedAccessException was unhandled by user code
Message=Access to the path 'C:\Users\USER\Desktop\fyp2\CMS TEST4\CMS\CMS\Upload' is denied.
my code is:
var guid = Guid.NewGuid();
if (File.HasFile)
{
var length = File.PostedFile.FileName.ToString().Length;
var ind = File.PostedFile.FileName.ToString().IndexOf('.');
var sdfs=guid.ToString()+File.PostedFile.FileName.ToString().Substring(ind, length - ind);
File.PostedFile.SaveAs("C:\\Users\\USER\\Desktop\\fyp2\\CMS TEST4\\CMS\\CMS\\Upload");
}
The ASP.NET worker process does not have access rights to that path. By default I believe IIS worker processes run under the Network service account. You can either add write rights for the folder to this account, or set up a new Application Pool with a different identity (i.e. a user that does have write rights).
As simple as the error puts it, your application requires the folder to have proper write permissions.
I'm asuming this is a Web Application. In that case, you'll need that the user which IIS uses to run applications has Write permissions over the specified folder.
The users directory is fairly locked down. If the account the web server is running under is not the specified user, it will not, by default, have access to the path. You can either grant explicit access to that path to the account running your web server, or create a folder with appropriate permissions external to that path and create a link on the user's desktop.
Looks like current user has not permission to save. Before writing try use FileSystemRights with AccessControlType.Allow to know permission info of the destination.