I have configured the .NET SDK in Visual Studio to use IAM credentials (which are being encrypted to the app.configs such as is described here: https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/net-dg-setup.html I then wrote a call to my S3 server to get a presigned URL so I could display it in my .NET desktop app. When I run the app from my computer (through VS or by clicking the Executable) the pictures load fine from S3. When I move the bin folder files (I copy the Release directory to the 5 client computers) it doesn't work on those machines!
I've thought about trying to run an install (which has several draw backs that stem from my lack of experience creating installers). The only thing I could see this changing, is if the encryption of the IAM key uses a MAC address and the installer re-requests the IAM credentials, then it would work.
The error I get on the other PC's is: "Failed to retrieve credentials from EC2 Instance Metadata Service."
The machines are on a network whose public IP is white listed to another IAM role with FullS3 Permissions but the Group the Security Key is in also has FullS3 permissions so I wouldn't think that would matter either.
I'm more than happy to answer any other questions people have because I really want to get it going! Thank you!
I found this article about 45 minutes after posting and after reading it about 3 times I finally saw it!
"SDK Store profiles are specific to a particular user on a particular host. They cannot be copied to other hosts or other users. For this reason, SDK Store profiles cannot be used in production applications."
and "Using a Credentials File
You can also store profiles in a credentials file, which can be used by the other AWS SDKs, the AWS CLI, and Tools for Windows PowerShell. To reduce the risk of accidentally exposing credentials, the credentials file should be stored separately from any project files, usually in the user's home folder. Be aware that the profiles in a credentials files are stored in plaintext."
So the answer is I have to provide a plaintext file with the credentials and simply put it somewhere I believe to be "safe" on the clients computer, then specify that location in the app.config file.
Related
I'm running a web application developed on ASP.NET; C# and SQL Server 2008; on Local Host on a Network.
It is showing an error 500.19 for some Permissions...
Can anyone help me out to solve this and run my website on localhost without hosting it online.....Have a look, What's the error is...
It might be the issue of permissions for the directory/files for your application.
Make sure you have given the full permission to the users types that will be accessing the application.
For adding/editing permissions, you can navigate to the concerned folder and right click on it, selec properties and then go to security tab wherein you can edit the permissions of existing users as well as add new users with specific permissions.
Also, if you have your application hosted on IIS, there is also an option for changing permissions which will again, open the folder for you and you will have to follow the same steps as mentioned above.
Hope this helps.
Such issue occurs when, some wrong or duplicate element added in web.config file.
Verify your web.config file.
Also confirm execute version of virtual directory (32 Bit / 64 Bit)
My goal is to get a status of the signature field in a PDF file that has CoSign signature fields (signed and unsigned). I need all fields not just the last signed field.
I have created a WCF endpoint (using C# VS2013 and the ARX SAPI API) to read all of the CoSign signature fields in a PDF. This works fine on two of my three SharePoint 2013 servers. The file is accessed by the WCF endpoint using the UNC path to the file in the SharePoint server document libraries. I am able to access all the files on all three servers via any Windows 7 file browser without any issues.
I have copied known good files across the servers and tested them all with the same result. On the problem server SAPISignatureFieldEnumInit returns error 1878850044. I cannot find any information on this error in the SAPI documentation.
I am hoping someone might have come across this before and have some guidance or helpful insight.
The hex value of -1878850044 is 0x90030604, and you can find what this value means in the API documentation:
0x90030604 -
"Failed to open the file. Check the file path and the user permissions
on this file."
Make sure your WCF service has sufficient permissions to access this file/folder (e.g. if the service is hosted in IIS, then you should give its ApplicationPoolIdentity read permissions to that folder).
I was given a website (coded in ASP.Net; C#, HTML, CSS, and Javascript) to maintain, and the original creators have no longer been in the company for quite some time. I wanted to move the development over to subversion to allow easy rollback/more than one developer to easily work on the files, and in the process of doing so (for an unrelated reason) the process wasn't succcessful.
I removed the version control temporarialy, and manually copied the original folder back to its original location.
Now, however, when people attempt to access the website a dialog appears requesting their username and password, and only users with administrator accounts can log into the website.
I never so much as opened the IIS manager (on a Windows 2003 server), nor are any of the files different to my knowledge, so I don't know why this change would have occured.
Anyone know what is wrong, or a path to troubleshoot?
I have found here an interesting blog that explains how to secure the visibility of the connection string from the developers. http://blogs.msdn.com/b/sqlazure/archive/2010/09/07/10058942.aspx
As I am the only developer on my project, I wouldn't be concerned about that, however I am concerned about two things
While deploying the package to Azure Cloud, is my connection
string within the project in risk to be seen by third party? Or is
the whole package file encrypted?
Once the package is deployed, can the connectionstring be read
from web? Or is it secure and bulletproof?
If you deploy using SSL (via Visual Studio or a tool like Cloudberry Explorer) then the config files get to the Azure data-centre ok.
Once they are there I believe the config files can be viewed by anyone who has
access to the blob storage account that you uploaded to
access to the Silverlight GUI that Microsoft provide
access to the 'Remote Desktop' option (which you have to enable with certificates).
access to any management certificate you might have uploaded
So basically, as long as the right people have the right credentials you are ok.
If you are the only person who knows the login to the Azure Web UI and you are the only one who knows the storage keys and has the certificate keys then I would say it's pretty bullet proof.
I have two copies of the same website on my IIS7.5 windows 2008 server:
Default Website/my_app
Beta/my_app
The code base for the two are identical, and they both have identical web.config files.
On the default website, ELMAH works and logs messages (to file), but on the Beta website it does not log anything. What can I check to see why it is not working?
I have compared the ACLs for both physical folders and they are the same.
All it need is a write permission for apppool identity.
We are using very simple webdeploy package for automagic managing ACLs.
You should check ACLs for appPools
I'm sure your site use different identities.