I have an mvc2 project built for .NET 3.5. I have a library that I wrote in 4.0 that I need for the 3.5 project, so I changed the target framework and now the anywhere the anti-forgery token it throws:
Validation of viewstate MAC failed. If this application is hosted by a
Web Farm or cluster, ensure that configuration specifies
the same validationKey and validation algorithm. AutoGenerate cannot
be used in a cluster.
I found this question but no luck with any of the suggestions. I created a static machine key in my config but it doesn't help. Anybody have any idea what could be the problem. I don't understand why it worked fine before.
You have to close all browser windows to continue.
The AntiForgeryToken cookie is a session-cookie, and is encrypted / decrypted using the machine key. If the machine key changes (or is set to auto-generate), then rendering the AntiForgeryToken will fail.
Restarting your browser windows will clear the cookie, and MVC will create a new, valid cookie next time.
Related
I have just created a hosted blazor webassembly pwa project, which generates client, server and shared projects, all fine. I start the solution and everything runs fine.
But after I start to add small changes to the projects it stops working with a message like this:
"Failed to find a valid digest in the 'integrity' attribute for resource '' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked."
I search the net and stack overflow and find others having almost the same problem. Some can do clean and rebuild to solve this, but that's not working for me.
So, what is this? Why is this happening, totally useless?
Is it the PWA feature? Should I create a new solution without the pwa enabled?
It started happening to me recently. Only on a published released solution. Not on local debug.
Clean+rebuild didn't work for me. I had to delete bin and obj folders from both Client and Server (note: tried client only and, it did not work but, did not try server only) then republish.
cf. Failed to find a valid digest in the 'integrity' attribute for resource in Blazor app
It now occurs each time I upgrade or downgrade a package.
I've done several tests and can confirm :
DLL are the right ones (SHA256 hash validated) on the server.
the string in the blazor.publish.boot.json is the right ones.
I was even able to get rid of the problem by reverting to the previous package version prior to the bug (which changes back the related entry in blazor.publish.boot.json). Which for me confirms a reference is not updated somewhere.
The only significant changes I've made recently are switching to VS2022 and .NET6. The bug appeared after I did my first successful publish on Azure through VS2022: 1st package upgrade after that triggered the bug.
I'm working on creating an MVC Web application backed by an API which uses IdentityServer3 and is compatible with Windows Authentication, but I'm losing my custom claims in the process.
To this end, I've deployed this project: https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source/MVC%20Authentication
When I deploy it to IIS7 I cannot access either of two pages which display claims information until I turn on Windows Authentication. When I do this, I have access to the secure Web Page that shows claims and the API that shows claims. This is promising, but these displayed claims are SidGroups, and Default claims, respectively. I lose my custom claims.
Monitoring traffic in Fiddler, I notice that when hitting the protected claims page, there are two failed attempts which 401 followed by the successful attempt but which displays the wrong claims.
Has anyone encountered this? Does any one know the location of a working example of a Windows Auth compatible IdentityServer? I've looked over several tutorials which imply it's possible but I don't think they are compatible with IdentityServer3.
We have a MobileFirst application that worked with Worklight 6.2 server - production also. We are using a http adapter: <connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
Currently we are changing the production server to 7.0.0. On Development Server we could test our application and all the functionalities were OK. We'we created the .war with the production server on build configuration and uploaded together with the android .wlapp . Now we receive 404 when the application tries to call any adapter function on production server. invokeProcedure onFailure returns UNEXPECTED_ERROR. This is with:
Server version: 7.0.0.00.20150312-0731
Project WAR version: 7.0.0.00.20150402-2001
Adapter name: XXXXX. Version: 7.0.0.00.20150402-2001
Application: XXXXX-android-0.9.7, Version: 7.0.0.00.20150402-2001
We have no security enabled in the application.
Is there something that must be enabled on Server in order to allow old type adapters call?
When we've tested with upgraded MobileFirst Development Studio 7.0.0.00.20150430 as development platform - same server version, and we got same 404 (Context not found), but there tries to connect with authorization/v1/clients/instance instead of /apps/services/api/XXXXX/android/query
Should a Server upgrade solve this problem? We've noticed that there are updates available.
The Server is on a https connection, but was same on WL 6.2.
By the description in the comments and the supplied messages.log, it is clear that you are attempting to use Application Authenticity Protection.
This feature worked in a certain way in v6.2 and it works in a different way in v6.3 and above.
From the comments it appears you are only adding the publickSigningKey - this is no longer enough.
See the updated Application Authenticity Protection tutorial for steps to follow: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-0/authentication-security/application-authenticity-protection/
General steps to follow:
Setup authenticationConfig.xml with the security test
Add the security test to the environment node in application-descriptor.xml
Add the publicSigningKey to the <publicSigningKey> element
Add the application package name <packageName> element
I believe you are missing step 4.
Note that you also able to now enable the Extended Authenticity mode; follow the instructions in the tutorial.
Note about step 3: obviously the same keystore used to generate the publicSigningKey must be used when you export the signed .apk file... otherwise there will be a mismatch and the authenticity challenge will fail.
In your authenticationConfig.xml, make sure you have the securityTest available (= not commented out like in the file you've supplied in the comments below.
In your application-descriptor.xml, you are missing the securityTest attribute in the Android environment element: <android version="0.9.9"> change to <android version="0.9.9" securityTest="customTests">
I'm having difficulty in integrating AEM 5.6.1 with Site Catalyst. It allows me to connect in the configuration successfully, but does not work on the framework setup.
I've followed the standard procedure to connect AEM to SC and it accepts my login in the configuration, but fails on the framework set up with the browser message 'We were not able to login to SiteCatalyst. Please check your credentials and try again.'. Behind the scenes in the server log;
12.12.2014 14:10:06.967 *WARN* [0:0:0:0:0:0:0:1 [1418393406764] POST /libs/cq/analytics/sitecatalyst/service.json HTTP/1.1] com.day.cq.analytics.sitecatalyst.impl.SitecatalystHttpClientImpl Data center 'https://api3.omniture.com/admin/1.3/rest/' responded with errors {"error":{"code":500,"message":"Internal Server Error"}}
12.12.2014 14:10:06.967 *ERROR* [0:0:0:0:0:0:0:1 [1418393406764] POST /libs/cq/analytics/sitecatalyst/service.json HTTP/1.1] com.day.cq.analytics.sitecatalyst.impl.servlets.SitecatalystServlet Call to SiteCatalyst method 'Company.GetReportSuites' failed com.day.cq.analytics.sitecatalyst.SitecatalystException: not authenticated
I've tried accessing via the API Explorer and it works.
I've tried the troubleshooting guide without success.
I can log in to Site Catalyst, I'm an admin, I am in the web services access group.
I've tried using a clean install of CQ5.6.1 with geometrixx - it doesn't work either.
I've tried this from a server and from a localhost/dev machine with the same results. No proxy. I've even tried using the shared secret as the password but then it doesn't connect at all, and fails on the configuration screen.
What might cause this to fail?
If it doesn't work with a fresh install and Geometrixx, then it's probably an Adobe bug. That's typically the first thing support will ask you about.
I would also verify using Geometrixx Outdoors, or a more recent demo site, on your fresh install, just to ensure it's not an outdated ClientLib issue.
I know this isn't a direct answer to your question, but honestly, I would approach the integration differently. I've worked with the AEM-SC framework and it's buggy at best. It's very finicky, it doesn't REALLY work the way the documentation claims, and it requires that you're very specific about what Clientlibs are on the page.
Moving forward, I think using Adobe Dynamic Tag Manager is the better approach, for many reasons. My understanding is that it's Adobe's recommendation as well. I'd consider moving to that. In AEM 5.6.1, you'll have to customize your integration with DTM, but it's not very hard.
Solution: Add a property on the configuration node for sitecatalyst: (eg. /etc/cloudservices/sitecatalyst/my-sc-configuration)
server=https://api.omniture.com/admin/1.2/rest/
it also seems to work with newer API versions such as https://api3.omniture.com/admin/1.3/rest/
It would appear that for 5.6.1 it ignores the OSGi configuration, at least for the configuration screens. With this extra property, the framework page loads without error and allows selection of the RSID.
I have a C# application (WinForms) (ClickOnce) whose repository is installed on a server that is about to crash, so my boss asked me to move the repository, but there are around 300 client machines which have the application installed.
The ClickOnce is signed with a Test Certificate.
Is it possible to move the repository without having to reinstall in the client machines?
Thanks in Advance
[EDIT]
I Have published the application to the new server, but the clients don't reach it, what else can I do? I think i should change something inside the manifest or something like that, but a actually don't know too much about ClickOnce... In any case, i would like to avoid the reinstallation on all the client machines, any ideas, suggestion? thanks in advance
The answer provided by Jhonny seemed promising to me, and I encountered an error when I tried it, which I had to solve. It had to do with certificates.
After following his setps, when I launch the ClickOnce app on the client machine, I get an error dialog: "Cannot Start Application".
When I click on the Details... button in the error dialog, the text file that opens shows that the app is trying to update from the Deployment Provider URL of the new server, but it gives this error:
"The deployment identity does not match the subscription."
The problem was the certificate used to publish the app on the old server was expired, and I had updated the certificate in the app published on the new server. The certificates didn't match.
The solution was to first publish the app to the old server with the new certificate, have the users open the app to get that update, then publish another new version with the Deployment URL of the new server, and copy the files to both servers. When the users updated the next time, they got the version of the app from the old server with the manifest pointing to the new server, and then, all subsequents updates were retrieved from the new server.
Here is what I have done, for people who may have the same issue.
Setup the new server on the publish package. (Project Properties, Publish Tab)
Publish to the new server
Copy the published files to the old server. (Include the .application file and the folder)
When the clients reach the old server, they will update, but the server location will be updated on the client to the new server name.
You could try to change the DNS alias so that it redirects to your new server.
The fact that the code signed using a certificate is not relevant, since code-signing certificates are not bound to a specific repository (as opposed to SSL certificates)
Btw, why don't you want to reinstall? The whole point of clickonce is to ease this kind of software update !!