virto commerce deployement from Github - virtocommerce

I have successfully deployed the virto platform and storefront on to azure.
the CMS content connection string was taken from the platform appsettings and assigned to the storefront CMS connection setting. The Api Hmac App Id and secret keys are assigned as per the documentation.
Platform and storefront are synced in azure with the latest.
however, when the storefront url is entered in the browser, it does not show the storefront, insted the following error occurs.
This page isn’t working our storename.azurewebsites.net is currently unable to handle this request.
HTTP ERROR 500
please advise if anyone encountered such error. Did I miss any other settings?

First of all, that is NOT CMS connection string related issue.
Second, try these:
restart platform app service
restart storefront app service
clear browser cookies / open page in anonymous mode. The url should start with https, not http
wait for 30 seconds as this could be a timeout issue on slower service configurations
Third: set ASPNETCORE_ENVIRONMENT=Development as described in https://learn.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-2.2#set-the-environment to get error stacktrace

Related

Docusign app getting error this page isn't working right now, local host can't currently handle this request, http error 500

I'm developing an app based on the Docusign C# Quickstart.
Its working fine on my development PC (Win 11) in Visual Studio 2019 using IIS Express.
However, when I publish it to IIS (v10) on my development PC it runs and I can authenticate with Docusign just fine (once I got the proper redirect URI registered: https://localhost/ds/callback) but the step that actually sends the envelope is returning the following error in the browser:
This page isn't working right now.
Local host can't handle this request
http error 500
Any help is appreciated. I logged a support ticket with Docusign, but still waiting for a response.
Quickstart is just an app to show you how to use DocuSign APIs.
The redirect after signing is back to localhost, and your app, once ready to be deployed to server, has to be set with a proper URL, at which point you'll need to update the redirect URI to the one based on your server.
The 500 error is coming from your app, not from DocuSign. You need to figure out why your app cannot handle the URL that is set for redirect after signing by DocuSign.
The base API address demo.docusign.net/restapi is used to reach the development/ test platform. The na4.docusign.net/restapi address is one of DocuSign's (many) production platforms.
Remember that, once you have passed the Go-Live process, you have two Client IDs (integration keys) one for the test platform, one for all of the production platforms. Each has its own settings.
Added
The error
This page isn't working right now.
Local host can't handle this request http error 500
Is from IIS. Use IIS logging to see the URL request that is coming in that can't be handled.
To see if it is the redirect from the initial OAuth Authorization Code grant URL, examine the initial URL redirect to account.docusign.com (prod URL).
The redirect contained as a query parameter in the initial OAuth redirect must:
Be correct for your instance of IIS.
Be allowed by your setting for the client ID (integration key) in DocuSign
1, Be properly handled by your IIS and its app.

API connect published api in developer portal can't work

https://new-console.ng.bluemix.net/docs/services/apiconnect/apic_tutorial.html#apic_tutorial_01
Follow previous link to do create loopback project named ibmsvt and do test locally, we can post and get.
then publish this api as running api app on bluemix and we will get api target url and tls file.
type url and tls in api designer invoke, and publish api product again.
check api connect service and we can find that published api product has been published, configure developer portal, and invite developers
login developer portal and register one app
subscribe app to api product and run post command.
We will see that we only get can't post error information...
Please see attachment info for error info and api file.
From the screen capture provided, it looks like you're displaying the logs for the loopback application deployed on bluemix. It also looks like the POST request from APIConnect hit the Bluemix application as well. However, I'm unable to see the exact message of the error. What error did you get when you execute the POST from APIConnect? I suspect the POST did not include the $(request.path), what did you change the invoke url to be ? Can provide the x-ibm-configuration section in your yaml file? It will be located in your /definitions.
Thanks and best regards,
I am just have the exact problem, and struggled for days on redoing the tutorial several times, but still met with the same problem until found the upper reply, and gave me a hint.
In the tutorial, it says like the following:
Update the following fields with the values you copied previously:
Invoke URL: Insert the API target URL. You must specify the secure protocol HTTPS. For example:
apiconnect-ca3283b0-525c-488d-993b-3ab72fca78d0.youremail-dev.apic.mybluemix.net
TLS Profile: Insert the API invoke tls-profile.
For example:
client:Loopback-client
The origininal URL is $(runtime-url)$(request.path)$(request.search).
And the correct URL after updating is like following:
https://apiconnect-ca3283b0-525c-488d-993b-3ab72fca78d0.youremail-dev.apic.mybluemix.net$(request.path)
no slash before $(request.path), and $(request.search) should be deleted.
I also checked a tutorial video, it also do like this, but the screen for this step is passed away very quickly, you will not pay attention to this detail normally.
https://www.youtube.com/watch?v=Qku71JLv8vA&list=PLFa8jnU0KqE2eW5E449ziaurv8obSbcou&index=3&cm_mc_uid=24774488665514672571374&cm_mc_sid_50200000=1468400063

Bigcommerce authentication get request only returns scope and code, context is missing

I am kicking off the Bigcommerce app installation process by following the instructions given in this official documentation page https://developer.bigcommerce.com/api/callback apparently I am following every thing. I have https Auth Callback url setup in the app configuration page
NOTE: I am using ngrok to tunnel my localhost to internet.
When Install my app I receive the code and scope objects in the Get Request but not the context object.
Please help me with what did I missed ? and how I can get the context object ?
UPDATE
I tested it without ngrok and its the same.

Using JMeter with ASP .NET MVC 4 web app returns 500 status error when logging into web app. Why?

I'm using JMeter to load test my web app. I created two HTTP Requests, one visit login page and the other, log into my account. The visit login page HTTP request works fine and returns 302 Found status. JMeter displays the login page and there 0% errors on that page.
However, when I try to login into my account using the POST Data I retrieved from Firebug POST, it doesn't work and returns a 500 status error.
I am having difficulty getting the logging into my account feature to work. I have tried to send a POST request with the following:
1) __RequestVerificationToken
2) languageDropDown (My web app requires it)
3) UserName
4) Password
but I am still getting the error.
I followed this tutorial as it's the only one on ASP.NET MVC web apps...
http://build-failed.blogspot.pt/2012/07/load-testing-aspnet-mvc-part-3-jmeter.html
But I didn't do the feedback form data because I don't need it. Just grab the general concepts and regular expression from that webpage and tried it on my app but it fails.
Why? How do I fix it?
Is it because I have cookies to store session and only unique users can login my web app at one time? I did add a cookie manager though.
BTW, this is on a deployed web application (not localhost).
Some photos, I blocked out all sensitive information (sorry) and some of the token's (Just in case?)
Are you sure you have static authentication token? May it dynamic?
Look at second video that deals with token at 5:37 min to understand how to extract dynamic authentication token.
Exept HTTP Cookie manager, try to add HTTP Cache manager

Fileupload authentication issue on Websphere 7

We are currently facing a production issue on Websphere 7 with respect to richfaces fileupload component. The problem description is that immediately after the file for upload is browsed and selected using this component, the basic authentication dialogbox appears asking for user credentials.
Following are the frameworks we are using in our project:
JSF 1.2 & Richfaces 3.3.3
Spring Framework 3.x
Spring Webflow 2.1
Spring Security 3.x (only basic authentication using login dialogbox)
The user is authenticated once when he wants to access the application at the beginning using basic authentication. All screens that dont use fileupload component are working fine. But if we use fileupload component, as I mentioned above, the file selection (even from local machine path) triggers the basic authentication dialogbox again. The strange thing is that this behaviour does not occur on our Dev Environment which uses Tomcat 6. On Tomcat, the fileupload is not triggering any user login and upload is working fine.
This problem is occuring only when the app. is deployed on Websphere 7. Can anybody please tell whether Websphere requires any additional configuration for accessing Files through this component ?
We have spent a lot of time investigating this problem without any meaningful results. As this is a production issue for us now, it is very critical and needs to be resolved at the earliest.
So please help in this regard. Thanks in advance.
I don't know the File Upload component, and the answer may well lie in the detail of how that works, but in general WebSphere will challenge if an HTTP request arrives for a protected resource and the request does not contain a valid LTPA cookie. The cookie is normally sent by the browser on each request when authentication has happended once, BUT it will only do so if it believes that the cookie is related to a given domain. So if the main part of your website were served from, say,
htpp://my.own.org.com/mysite
and the file upload were related to a subtly different host
http://my.other/filesite
Then the cookie would not be sent, and a challenge would result.
My approach to diagnosing this would be get some kind of traffic sniffer. See exactly what is flowing and the addresses being used. I'm predicting that you will see the LTPA cookie in the usual case and not in the upload case. Then it's a matter of figuring out "why".