While using Inno Setup to create an installer a need as arisen to verify a user's credentials during the installation process. The application has been out in production for a while and the only need to move to an installer is due to support for NPAPI within web browsers being deprecated. There is already a way that the application verifies a user's credentials before launching the application that I'm trying to take advantage of, which is through a SOAP request. The verification process is just not making sure the user is authorized but also assigning them a token that prevents their information from having to be sent multiple times during the running of the application.
My question, is there a way to make the SOAP request to verify a user's credentials through during the installation process? If so, how would this be accomplished?
SOAP is just an XML over HTTP.
So you can use the WinHttpRequest class:
WinHttpReq := CreateOleObject('WinHttp.WinHttpRequest.5.1');
WinHttpReq.Open('GET', 'http://soapserver.example.com/', False);
WinHttpReq.SetRequestHeader('Content-Type', 'application/soap+xml;charset=UTF-8');
WinHttpReq.SetRequestHeader('SOAPAction', '...');
WinHttpReq.Send('<data/>');
{ WinHttpReq.ResponseText will hold the SOAP response }
See also HTTP POST request in Inno Setup Script.
To parse the SOAP response, you can use the Msxml2.DOMDocument class:
How to read and write XML document node values?
Related
I'm trying to use WSO2 API Manager 1.10.0 on an existent micro-services project with REST APIs following WSO2 tutorial.
I have installed it on my computer as well as a copy of my application and configured AM to manage requests (GET, POST and DELETE) to my resource but I always obtain a "Response code 0" with Response Header
{
"error": "no response from server"
}
Trying to contact my application using Advanced REST Client I obtain 200 with the correct result.
My APIs use a token inside the header to authenticate the user passed so I have implemented a dummy API without authentication but I still have the same issue.
I have tried also the Cloud version with our test server but still obtaining the same result.
I found this guide http://wso2.com/blogs/cloud/video-setting-up-custom-url-for-api-store-and-gateway/ but I don't know if this can be a solution for the problem in localhost.
Setting up the custom url in WSO2 API Cloud wont help. Thats there for a different purpose. There are two things you can do.
If you are interested in going ahead with the cloud version, you can get help from them. You can send a support request and the cloud team will help.
You can troubleshoot your local instance. When doing so, first, try to invoke your api via curl and see whether it gets a response. Sometime, your api can work fine, but due to some reasons, the result might not reach the api console.
If the curl works fine or not, you can check the logs to see whether there are any errors printed. Some more questions:
Is your backend service exposed via http or https?
If it is https, then if its certificate is not a CA signed one, API Manager will fail during the handshake. If so, you will have to add the cert to api managers client-truststore.jks
In the cloud scenario, your backend should be accessible from internet and the certificate story is valid for cloud too.
Are you trying to access the api using swagger console (or any web application). There are couple of reasons you could encounter this issue. one could be certificate not installed in the browser.
If this happens you should see some error log in the api manager console (something related to CA not found). for that first you can copy the backend url (swagger console shows the url it used to send the request) and paste it on a new browser window and install the certificate to the browser.
also you can get an idea about the issue by using a tool like firebug and check the request. (it will show the error for not connecting the AM)
Finally I have found the issue: the API Manager does not accept plain text response, responding using a JSON solves the problem.
Using other mediatype such as XML or TEXT/HTML it reports 406, with text plain it returns Error 0.
*I am completely new to ember.js.
I'm building a dashboard that requires an login (authentication page). I'd want to find a secure way to send credentials via an api call to the server side code, and I will be expecting a session token as a response, and I'd like to store that session token in a cookie.
I've looked into ember-auth, but I feel like it's for apps where the front end and the back end are in the same repo, but that's not my case.
What suggestions do you guys have?
My only restriction is that it has to be done in ember.js
Ember-auth isn't necessarily just for apps. You can configure the endpoints like signInEndPoint and signOutEndPoint to point to the urls that need to be hit on your server to do authentication.
Also there isn't any reason to bundle the client-side and server-side in the same repository here. The demo does this because the asset pipeline support in rails is very convenient for demoing, typically for avoiding a front-end build step.
You can treat it as just a library file that you include alongside ember.
I'm very novice when it comes to web applications and ASP.
Recently, I've been experimenting with the Microsoft Sync Toolkit to synchronize databases over a OData web service.
The obvious question here is: Once the service is set up and published - so it is open for anyone knowing the URL - how to prevent unauthorized users from accessing this service.
Please note: Basic authentication of forms authentication - as far my little web development knowledge reaches - doesn't seem to be appropriate for this task, as it's not a web page that the client is trying to reach - where the page can display / or re-direct a logon request - it's a service that we are accessing here.
To make things more difficult, for the client-side syncing I'm using a 3rd party library/sync-provider that only accepts a URL for the service. So, there's no way (I think) I can experiment with incorporating login credentials inside a request header etc.
I assume the best bet would be embedding the login credentials inside the URL and use that for the 3rd party library.
Can somebody please direct me how to to set up such thing on the server? I would prefer to have somehow somewhere in the server-side code a place where I can check for the credentials and based upon it to proceed or abort (return 401) the service request.
I could not find any place where to hook such code into the sync service. Although somebody in MSDN suggested to handle the _OnBeginSyncRequest event, there is no way to access the web-request header from within that method.
Is there by-any-chance a global object accessible from everywhere from which I can access the request header? Could anyone please help with this?
And last, I would prefer a plain User / Password string pair. It should not necessarily (or rather not) have anything to do with windows or directory accounts. I would prefer in my code to simple check against plain strings, such if(userStr == "Authenticated user" && passwordStr == "Correct Password").
if you are using SOAP web service, you can use WS-Security usernametoken which adds your user name and password to the request header, otherwise you can add username and password as parameters in your webservice and then simply validate it on the server side. i.e.
instead of
bool SyncData(datatable)
it becomes
bool SyncData(datatable, username, password)
note for web service you will authenticate per call, if you want to do it per session, you need first login with username password, retrieves a token than on each subsequent call your service with the token.
You would also use SSL to secure the channel so username and password aren't transmitted as plain text.
Hey there code warriors and stack exchangers.
I have been trying in vain to set credentials for a web service. I wrote the webservice in Websphere (java ee) and it requires a username and password in the header for any of the services to be called. I can run it fine in SOAP UI, but I need to be able to hit it from a .net web client.
So far I have tried setting the credentials like so...
dlc.ClientCredentials.UserName.UserName = "idiotCreds";
dlc.ClientCredentials.UserName.Password = "someWhackyPWD";
And so far I have just recieved this exception
security.wssecurity.WSSContextImpl.s02: com.ibm.websphere.security.WSSecurityException: Exception org.apache.axis2.AxisFault: CWWSS6500E: There is no caller identity candidate that can be used to login. ocurred while running action: com.ibm.ws.wssecurity.handler.WSSecurityConsumerHandler$1#42304230
Which I am guessing is telling me that there are no credentials being set...
Even though I set the client credentials. Do I need to create and add a soap header manually here? I thought that was supposed to be handled by that client object? Any ideas fellas? Thanks
The question and answer in this SO thread will provide those who seek answers with the solutions they need.
https://stackoverflow.com/a/12159837/729820
This is a similar situation to the one raised in this question:
Javascript Calling a Rest API with App Name and App Password - How Can i Secure it
Here is the architecture overview:
The site is Html5/jquerymobile
It contacts what I call a "Wrapper" service.... This is a REST API I wrote in C#, to contact another 3rd party REST API. I do this because there are credentials in the Header and the API uses Basic Authentication. Credentials are therefore not publicized as they are only known server-side.
My "Wrapper" service does not currently implement any additional security. It is currently accessible from anywhere. The easiest and quickest way to lock it down is to restrict by IP, so no other IP anywhere except the server can actually contact my wrapper service.
The questions:
Is the locking by IP the only way to ensure that the API won't get hammered if it was otherwise accessible from anywhere?
If I convert this using Phonegap (which I have... and deployed successfully on Android), obviously the native app won't work if the web service is restricted.
Is there a way around this so I can allow traffic only from the mobile app, and not from any other source? I'm thinking along the lines of MD5 hash or something that could be sent to the wrapper API.. but unfortunately I'm thinking that info can easily be "sniffed".
Is my only viable option here to release the app as a web app, forcing browser use, thereby removing any concerns about allowing my web service to be hammered??
I believe the answer to this is a combination of a user token and encrypting the message through SSL.
The server can issue a valid user a token so we can identify him in future requests.
Encrypting it via SSL will ensure that this token cannot be sniffed.
https://security.stackexchange.com/questions/12531/ssl-with-get-and-post