This is more of a technical question; I don't have any code to offer as I've only begun experimenting with basic output in CPP, and I currently see this as my most difficult task.
In a desktop application I'm coding, I am trying to allow users to sign into their online account they have with my web app, but obviously it would wouldn't make sense to include the same DB connection I use for hosting my site...
Is there a way I can send JUST username and password values over POST in cpp and use these values to achieve desired functionality in PHP?
Hopefully my question makes sense; I'm simply wondering how one would interact with a web server over CPP (without a direct db connection...)
Related
So basically i'm developing a piece of software that will allow user to call any number he wants right from the website. So i need some help in choosing the correct platform or semi cheap service to use. I guess i need a solution with open API because i want to make a db entry (want to record duration and date) for every call made from website.
I've started research and stumbled upon couple of open source solutions: Asterisk and FreeSWITCH. Trying them out right now, but i still have poor understanding of how SIP works. If it will be a softphone will the user have need to install it on their pc or there are server solutions
One possible solution that works with any SIP server is to use PJSUA Python bindings and to implement in Python a basic softphone. Thus your web application will be seen by the SIP server just as a regular soft phone and the server configuration is much easier.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a database which I consider to be my application and a website acting as a user interface for that application. It is now time to add more user interfaces to my application (phone apps etc).
Keeping this in mind, I have come up with a web service architecture to feed data to all my user interfaces. I would like to sanity check this with the brains on stack overflow. Btw - this is all Azure hosted.
Database, as is.
Core web service - this handles all important methods and invokes the main processes on the DB. For example, registration. This will also automatically queue emails to be sent, etc.
Web Services for each UI (website, phone app) - these are specific methods for the UI data calls - e.g. GetDataForRegistrationPage - specific to the website and not needed for the app. The app would have different requirements.
So far I think this is reasonable though I'm interested in your opinions. I would like a bit of help with the next bit: how they communicate.
I would like the Core web service to be a WCF Service that can ONLY be accessed on named pipe endpoints - ensuring that only the client web services can communicate with them (I can guarantee they are on the same machine).
I would like the Client Web Services to bind to their applications by TCP or http. The website will be on a separate machine but on the same network and so is a good contender for TCP. The apps will of course be on clients and would be best as http I believe.
I am worried that I've introduced too many steps with this design. Using registration as an example, the user would register using the website page which goes to the web server which would invoke the registration method on the website web service, which would invoke the registration method on the core web service, which would invoke registration on the database.
Thank you for your thoughts!
(I posted the below as answer but got told off. If we really want to be anal about this then I guess no one should have posted anything as answer as there is no real answer - I was asking for opinions, but anyway...)
Just in case it is of any interest to others having similar design questions. I have decided to get rid of the core service idea and just use a class library shared between each client service.
Pros: Easier to develop, one less complication (setting up named pipes seems impossible to me) and one less process to get involved (even if it is on the same machine).
Cons: Each service now HAS to be on Azure, otherwise it cannot access the Azure storage facilities. I will be using the queue to schedule emails. With the first approach I could have potentially hosted one service on a completely separate platform.
Feel free to comment with any ideas or observations. Thank you for the input, Ramiramilu and Markus.
Your approach seems to provide a good separation of concerns. Depending on the size of your project, it might be a bit too much. If you are looking for a way to simplify your architecture, here are my thoughts:
Client WebServices
I'd propose to analyze how big the differences of the Client WebServices really are or whether it is possible to set up a common service for all clients. Even if you were able to move a lot of shared code to the Core WebService, you'd have to implementent very similar interfaces over and over again. Of course this implies that there won't be a specific WebService that is tailored to the needs of a specific client. If you build on WCF, you can also offer services with different bindings so that e.g. the WebSite accesses the service using a NetTcpBinding whereas another client communicates with the same service over a SOAP interface (WebHttpBinding or WSHttpBinding whichever fits your needs). This would be much more efficient because you'd not have to implement common building blocks like authentication and authorization for each Client WebService.
Also you might want to have a look at ASP.NET WebAPI and consider building a REST API that should be accessible from all devices - though it is as efficient as a TCP binding. You could also host your Web API in the WebSite project so that you can use it both from other client and for AJAX requests. As your WebSite is accessible from the internet anyway, this is also a good approach from an infrastructure point of view.
Core WebService
You could substitute a class library for the Core WebService. The Client WebService(s) can integrate this much easier without having to deal with additional complexity, e.g. for authenticating at the Core WebService.
As you want to host the Core WebService on the same machine anyway, I'd only build a service if there is a strong reason for it. I can't come up with one now.
Conclusion
If your requirements are only to add some clients with a limited set of capabilities, I'd suggest to add a Web API to your WebSite project and access it from the other clients. See this link for more information.
I am building a windows 8 application which will be used as the interface to a web service I have running.
I need to find a safe way of encrypting sensitive data to pass, then decrypt it the other end.
Two things I need to do (as they may require separate methods);
1) User will enter a username and password which needs to be authenticated
2) User will enter personal information to be saved.
Now I have looked at many encryption/decryption methods, but I cannot find anything which is common place between the two. For example System.Security.Cryptography is not available within the windows 8 app, and my website can't use CryptographicEngine.
I am basically trying to find the best way to DO what I need to do. Along with a way of actually doing it in code.
You will not be able to use the same namespaces, as you have recognized. What you need to do is settle on a standard crypto algorithm on both ends.
Here is a discussion for one approach on the Win8 side using AES256. http://social.msdn.microsoft.com/Forums/en/winappswithcsharp/thread/8f9ecac4-80d2-47c8-8c41-9d7877565bf5
Here is a solution for doing AES256 with regular .NET
http://msdn.microsoft.com/en-us/magazine/cc164055.aspx
If you just need to secure the channel, then use an HTTPS web service, that's what HTTPS was designed for. The client-side HttpWebRequest class should just do the rest for you.
You'll need a certificate on the web server.
In the place I work there are some software written in C# and some written in C++ (the most important ones). Some time ago we decided it would be a good idea to track any possible problem in the software, by sending stack trace and exception information over a web service. So I came with a WCF Service, that gets the information and store them on a database and send an automatic e-mail. It worked, we had to secure it through password, it's done, but now I want our other software, the one written in C++, to use this webservice (this software is used both on windows and linux, so we can't just make a call to another software in the user machine).
I've googled about it, and found this tutorial on how to use gSOAP, which so far didn't help me very much (lots of errors, it is not very detailed, and the web.config file is impossible to read). I was wondering if is there any other way to achieve this. In adition, since I'm using authentication on my webservice, it now has a wsHttpBinding (which AFAIK isn't supported by gSOAP).
Can you guys help me out?
Since your WCF service is in C# with .NET, and the only issue is getting the C++ application to be able to talk to it, one way is to follow the advice in REST / SOAP Endpoints for a WCF service and related articles.
Your C# programs continue to have the full SOAP access to your service.
Your C++ programs could do something like this for REST access:
"Browse" to the HTTP GET URL for the service command you wanted.
Then toss (or parse and use) whatever response came back.
It is a pretty minimal change to your WCF service to offer both SOAP and REST.
The REST ability opens your service to JavaScript as well as C++ clients.
You may need to restrict the interface to simple data, or class objects that are easy to parse in C++.
Will the machines running the C++ applications have the .NET Framework installed?
Check out: Create WCF service for unmanaged C++ clients
I am looking on advice on how best to approach a new project I need to develop. From the outset I must add, I have 0 experience with Web development on any level.
What I need to do is provide a web interface through the browser which will communicate with a server back end. The data retrieved will be sourced from either a DB or from another source - external device which the server itself will communicate with via IP. The data retrieved from the external device will always be a string format of n length (non unicode) and the DB data will mostly be strings and numbers with the odd blob thrown in (storing a picture). The communication will always go from the Client (web browser) to the Server. I don't believe that the server would need to instigate the comms.
I have Delphi XE, so started looking at using a REST server for communication and I think that seems to be OK. However, from what I can see, I need to create HTML web pages to "render" the data on the web browser. Is that true? Can I use the IW components with a REST server? If so, I'm not sure how to get the data to/from the browser UI. Am I better of investigating Ruby on Rails perhaps? From what I read on a different thread in here, it's based on MVC and some other areas which I feel, design wise, would fit how I would create the application (I was planning on creating the app based on the MVP or similar design pattern).
I think REST makes the most sense, so if the IW components can't be used, are there any 3rd party products I can use which would let me design "pretty" UI html. Given I don't know java script, would that be a stumbling block with REST too.
Thanks and hopefully I have provided enough information.
Thanks
Jason
Will a human being be responsible for typing the data retrieved from your external device into a web page?
If so, and you have no web development experience, Intraweb is definitely the way to go for Delphi programmers wanting to build a web application without learning new skills. For additional components to create a prettier UI I suggest using TMS Software's Intraweb Component Pack Pro.
If you don't need a human being to manually type in this data then you don't need Intraweb at all. Instead you would write a client application which presumably interrogated your external device for the data and then transmitted it to the REST server. Look at the documentation you've used to build your REST server and it should have a section on how to build a REST client.
You can build an ISAPI module with delphi that does the job, or include a HTTP server right into you executable with Indy, ICS or Synapse.
ISAPI will give you the freedom to choose Apache or IIS and give you all their power this way. Embeded HTTP server will give you a nice small application in which you control all ascpects of how it works.
Yes go with REST as it is simple and clean. All you need is to think and design the API (functions that your server will support). You can bind the APIs to the URL schema thus using the REST principle. I would do it simply like this.
A client makes a request. You show some form of GUI (load or render a HTML page with possible javascript)
User makes an action, you call appropriate API (or the user does it directly).
Show the user some result
Just guide the user process through a series of API calls until the result is made
You can use plain HTML and then add javascript if needed (jquery) or you can use ExtJS from Sencha which makes building a nice GUI a lot easier and is very well structured.
I would not use any "WYSIWYG" web tools. Plain old HTML written by your favorite editor is still the king in my opinion.