I'm trying to wrap my brain around setting up load testing secure azure web applications. I want to push a load test to the cloud, which is pretty simple given we are using VS online. However, when running multiple users I get several errors. I think the errors revolve around a single account trying to gain authorization to web app simulated with multiple 'virtual users.'
Errors: https://login.microsoftonline.com/common/login----{POST} Context parameter $HIDDEN1.ctx not found in test context
https://mysite.azurewebsites.net/----{POST} Context parameter $HIDDEN1.code not found in test context
a slew of socket exceptions:
https://localhost:port/skypetoc/v1/pnr/parse----{POST} connection actively refused
ValidateResponseUrl errors
https://mysite.azurewebsites.net/----{GET} The value of the expectedresponseUrl property 'https://login.microsoftonline.com/common/oauth2/authorize does not equal the actual response url https://mysite.azurewebsites.net querystring parameters were ignored.
running this test locally with a single user account works fine. pushing to the cloud under a single login account with multiple simulated users yields all these errors.
Questions:
1. Do I need to create n number of user accounts for this to work properly?
2. Do I just need to create custom plugins at the request level to get new auth tokens per user request?
3. Is there any built in support for this kind of stuff in Visual Studio Online Azure load testing?
I really don't want to test the performance of login since its out of my hands. but I do want to test the performance of my web app under load for other functions.
Visual Studio Online does not allow localhost to be the hostname in your callback URL. You can edit the hosts file on your local computer to map a hostname to 127.0.0.1. Then use this hostname when you register your app. Or, you can deploy your app when testing to a Microsoft Azure website to be able to debug and use HTTPS for the callback URL. See: https://www.visualstudio.com/en-us/integrate/get-started-auth-oauth2-vsi.aspx
Related
I have a back-end process that I would like to use to connect to Evernote and download some notes. I thought I could use the developer token which I used successfully in the sandbox environment but when I tried to set it up in Production the Evernote support team said that it was discontinued and not allowed to be used in Production.
I then tried to use the
ENSession.SetSharedSessionConsumerKey
but that brought up a web browser to verify that I could use the service. The problem is this is a back-end process and I don't want a manual step of clicking the authorization web form.
Has anyone have a solution to do this?
Looking for a design solution.
We are currently migrating our old site installed in Windows Server IIS to Cloud-based Azure App service or Azure Service fabric.
We have multiple clients but one of the requirement is to move clients one by one.
I.e They want us to use the same DNS, but based on brands it should route to the new or old site.
so for example, we have 2 brands
Brand 1 - moved to a new site
Brand 2 - still using the old site.
So we when the request comes
For www.Mysite.com/brand1 then it should call Site hosted in Azure.
For www.Mysite.com/brand2 it should call old site hosted in windows
server IIS.
Is this feasible? If yes what are the options I have?
I saw options to Redirect a Domain by modifying .htaccess file.
Currently looking for options to finalize the design approach i.e moving all client at once or moving one by one. But later is preferred.
It is possible to use an Azure Function to handle the redirect. I have done something similar in order to create our own short urls for text messages. Before redirecting you can inspect the original url to determine where to redirect too.
Check out this link
Most likely a good business case for having an azure application gateway as its made for redirecting traffic based on the route requested. the gateway would need to be register under the domain name you want visible and you would then configure the routing rules on the app gateway resource. your azure resource and your on prem resource would be considered your backend pools
www.Mysite.com/brand1 -> point to my new cloud server pool
www.Mysite.com/brand2-> point to my existing app server pool
Linking the azure docs on this.
https://learn.microsoft.com/en-us/azure/application-gateway/overview
I am trying to implement SkyDrive API into my Asp.net mvc3 application.I tried to create app in Microsoft using this tutorial for implementing user authentication , but I am facing a problem in Callback Url, because Microsoft forces me to add a real domain and I want to use my localhost in order to develop it right now.
Alternatively you could add a fake domain to your
/etc/hosts (Linux)
C:\Windows\System32\drivers\etc\hosts (windows)
file. Just add the following lines:
127.0.0.1 www.yourfakedomain.de
After adding that line you can choose in Microsoft OneDrive App-Center something like
http://www.yourfakedomain.de/blabla.php
as your redirect uri.
Since your operating system thinks that domain belongs to localhost you will be able to get your authentication code just normally at your local test domain ;-)
How would SkyDrive call code on your local machine?
One way to do it is to first mock SkyDrive in your application -- that is, you don't call the real SkyDrive, just a service that you have running locally that acts as if it is SkyDrive. You can use that to develop and debug your application to some extent.
Then you can deploy your application to a test server on the Internet, so that SkyDrive can do the callback, and you can test it there and make the necessary modifications before you deploy to an actual production server.
I find a solution for my problem, I used pageKite to solve my problem. pagekite gave me an alternative to my localhost by mapping my localhost to a real domain. so I added that domain to my app in Microsoft and its working.
I have an azure cloud service with a couple worker roles, a WCF web role and a normal web role containing a couple aspx pages. Both roles are set to use https endpoints.
When testing locally in Visual studio using IIS the default.aspx page and the servicename.svc page both open in the browser. When I publish to azure though, the URL with the random string of characters opens the directory containing the service definition, but I can’t access the default.aspx page from that URL.
For example if my URL is randomstring.cloudapp.net after publishing, randomstring.cloudapp.net/wcfservice.svc works, but randomstring.cloudapp.net/default.aspx does not. I can get to the other page by using the IP address given in azure, but this isn’t really what I need. Furthermore, the cloud service URL does not work at all. mycloudservice.cloudapp.net results in webpage not found.
Do I need to do something special in order to get both the service, and the aspx pages to show up under mycloudservice.cloudapp.net? I can post the config files if need be, but as of right now, I don't think there relevant to the problem.
EDIT:
Just to clarify, I have now published to production, and the service is working [mycloudservice].cloudapp.net/[mywcfservice] and I can get to the website without a 404 error if I enter the port like [mycloudservice].cloudapp.net:8081/default.aspx . Is there a way to make everything show up under [mycloudservice].cloudapp.net/ without entering the port number so I can just type in [mycloudservice].cloudapp.net/[mywcfservice] AND [mycloudservice].cloudapp.net/default.aspx into the browser?
First, I guess you published your project to the stage slot of your cloud service. It's [Deployment ID].cloudapp.net. You will use the URL you specified if you deploy it to production slot.
Ref the problem, that '[randomstring].cloudapp.net/default.aspx' doesn't work, I'm not sure what you mean by 'doesn't work'. Is it 404 erroe? Or some asp.net runtime error. More information might be helpful.
Check the port numbers. Each of the endpoints (the wcf endpoint and the web endpoint) need to be on different port numbers. You'll need to access them as such when published to Azure.
The random-name issue is from publishing to Staging vs Production, as #Shaun pointed out.
First of all, I took a look to every related topic on her about this issue. However non of them was successful in answering my question fully.
Currently I am working on a desktop app, coded in C#/wpf, that requires MySQL connection both for authentication and storing user custom lists etc.
However, the problem is that apparently allowing everyone to remotely connect to MySQL db is not good practice. Also, my current host requires IPs to be whitelisted before they can connect to the db.
What are my options on this?
Thank you in advance
You should look into creating a web service (SOAP), http web-api (REST) or some other middleware to abstract your data storage.
This has the benefits of:
Allows you to move much of the business logic out of your desktop app and into middle ware
Allows you to keep business logic out of sql which might be a bottleneck
Allows you to update your business logic without redistributing your desktop app (easier if you don't have direct control of all the desktops).
Allowing you to control authentication (many web servers have their own modules, method of authentication). Your app would control access and access storage under it's own service account.
Allows you to complete change your data storage (let's say in the future you store some in sql, some in mongodb, some in cloud storage - once again, without having to update all your desktops.
Allows you to scale out your front ends and even possibly scale out your backend storage (for example, read/write DB replicas)
If you're already working with C#, then the new MVC4 web-api should be a good fit. Read more here:
http://www.asp.net/web-api
If you go that route you could control access in your service and have your service access the database either via credentials in a connection string or if you use IIS, credentials on the application pool mapped to your site.
If you're shipping your desktop app (you're not hosting the DB) then you can also self host web-api in it's own exe if your customers don't want to install/manage IIS.
Finally, if your mysql is online, your middleware could be in the cloud (azure etc...)
Create a web service, such as with WCF or MVC Web API where your app can pass through their credentials and authenticate. I'd recommend https for transport security.