How to test a server API (REST) including interactions from multiple users/clients with symfony? - rest

We have a supplier that develops a linux-server for us exposing a REST API. We are developing a client application that uses this REST API. Multiple clients running this client applications work together and e.g. have a chat functionality. I would now like to write tests using the rest-API to verify if the server logic for this chat functionality is working: e.g. "Does client Jane receive the correct message if client Tarzan is sending a message".
I am thinking about something like this (pseudo-code):
client_tarzan = createclient()
client_jane = createclient()
#the actual login logic is hidden to make the example easier
client_tarzan.login_to_server
client_jane.login_to_server
client_tarzan->request('POST‘,hello_message_for_jane)
received_message = client_jane->request('GET‘,inbox_path)
expect(received_message).to be(expected_message)
The server needs the REST API calls from Tarzan and Jane to be coming from different IP addresses as it internally uses the IP addresses in its logic.
Is this possible with synfony?
How would I start to do something like that?
Do I need to do something special when interfacing the linux server (e.g. run it in a VM?) as I cannot imagine how simfony would be able to create actual TCP packages coming from different IP addresses in order to make the server believe that the two clients are actually separate. I guess this is the core of my question.

Symfony's test-client supports faking IP addresses and you can create multiple clients in a test.
The following example should give you an idea how to get started:
$client1 = static::createClient([], ['REMOTE_ADDR' => '11.11.11.11']);
$client2 = static::createClient([], ['REMOTE_ADDR' => '22.22.22.22']);
$client1->request('POST', '/say', ['message' => 'Hi']);
$client2->request('GET', '/chat');
For further guidance please consult the documentation chapter: Working with the Test Client

Related

Google SMTP Server vs Sending Email via Google Apps Service Account

I have an application that I've been spending way too much time on trying to send an email via a service account that I setup in my google apps account.
I was wondering if should continue down this overly complex method of using a service account or if I should just use Gmail's SMTP server. The only function I need is to actually send an email.
Are there any pros/cons to simply using Gmail's SMTP server vs setting up a service account and calling Google's API to send emails? If it makes a difference this will be sort of a batch email in that it will send to many people at once.
Please consider the following:
I guess you should majorly be concerned on sending batch emails. If you don't do it right you might have problems. To avoid those problems make sure to follow the Bulk Senders Guidelines here https://support.google.com/a/answer/81126 Another factor to take into account is the email authentication. When using smtp, make sure all email sent will pass SPF and DKIM to prevent being marked as spam or worse, getting emails rejected. If you use the Gmail API then all you need to do is make sure you set up SPF by following the steps here https://support.google.com/a/answer/178723?hl=en and DKIM by following the steps here https://support.google.com/a/answer/174126?hl=en As per the GMAIL API quotas, you can use 1,000,000,000 units per day so I don't think that will be a problem. The benefit of using SMTP is that you can use SMTP RELAY https://support.google.com/a/answer/2956491 which gives you a way much higher limit when sending emails in case the Bulk Senders Guidelines is something that won't work for you.
In summary, if all you are looking for is to send batch emails, then I guess going with SMTP is easier. Hope this helps!
For just ordinary usage by one user, SMTP will work fine except API has the advantage on server-side for the sysadmin for security.
Differences are theoretical for web service, web application development. Both are ways to give access or to interact with their server. Nowadays REST is used for integrating their service for custom software development, their one part will have F/OSS implementation like OAuth. With REST API we get some extra advantages but that is for integrating for professional grade software development. SMTP relay is less secure.
Take as 2 servers with two technologies. That "Google Apps Service Account" one modern web application supporting Representational State Transfer(REST) API to give access to resource, interact with the server. SMTP one is older web software using Simple Object Access Protocol (SOAP). You can search with SOAP vs REST to understand the basics.
Google SMTP Server is traditional SMTP traditional SMTP relay service. Advantages are -- easy to setup by the users, lesser documentation to help the users to use etc. Disadvantage are they are less secure, plus all inherited disadvantages of SOAP.
"Google Apps Service Account" is modern web application developed in service oriented architecture providing RESTful API for server to server communication over TCP/IP. Advantages are easy to integrate with custom software using open source authentication library (they use OAuth), REST provide more control on sending request, username-password for communication can be avoided, extensive examples of usage, more secure, granular control to operation on server, JSON response has common meaningful format etc. Disadvantages are related to common disadvantages of SOA, Web Hook, RESTful API, difficult to use by a new user etc.
In real, it is basically one web software supporting both ways. One always should use DKIM, SPF etc as anti-spoofing measures.

Block other xmpp client from accessing my ejabberd server

I developed chat application for mobile platform which uses eJabberd xmpp chat server configured in my public Ubuntu machine.
To make the server connection i used https://mydomainname.com:5280/http-bind so how to protect this to access only by my client application not others.
Now my server is accessible by any client like pidgin, adium etc How to block this.
You can modify ejabberd to have a custom authentication that integrate a variation from the specification and implement that in your client. That way, unmodified standard client will not be able to read it.
However, as your client is Javascript and code is visible, it will still be possible to patch existing client to implement your variation, but there is not way around this. The approach of "shared secret" means that if the secret is found, other clients could find a way to connect. The secret is even less difficult to find when your code is public (even if obfuscated).

Sending multiple REST calls at once

I want to send multiple simple REST calls at once using different user credentials.
For example, I want to send the following GET request 10 times: "http://localhost/ALS/api/risto/1.0/ElementMappings", using basic authentication (username/password). All requests should be made using different credentials, and all requests should be sent at the exact same time.
I need to test the handling of concurrent requests.
Is there any tool that may help me in achieving this?
You are looking for any of the automated testing frameworks with decent HTTP support -- for example, Apache JMeter.

multiple registration of transport in xmpp protocol

I am working on xmpp protocol and I came across with Gateway concept, in which it allows to communicate to services which uses another protocol like msn,aim,yahoo etc ..
As far as I understand I beleive that it allows only 1 registration for a particular gateway at a time.For example I can register only 1 msn account at a time.I'am not sure if its really true.
Is it possible to register more that 1 account for a particular gateway and how?Please help me with this..
That is true. All gateways I know (e.g. spectrum) only allow one registration per instance. But you can run multiple instances of the smae gateway type e.g.:
icq1.jabberserver.com
icq2.jabberserver.com
That is, additional to run mutliple gateway components to different IM neworks, like
gtalk.jabberserver.com
irc.jabberserver.com
icq.jabberserver.com
msn.jabberserver.com
...
you also run multiple instances of the same gateway component on your server. Please not that this are (internal and/or external) components to your XMPP server and not individual XMPP servers!

Is an API RESTful if it allows permanent requests (server push)

I am writing a REST API providing CRUD operations on resources.
I'd like the users to be able to register to some resources changes and get the updates via server push. For the server push I will provide support for reverse ajax, hidden iframe and websockets. In order to be as REST as possible I created a Streaming resource which handles the registrations and the connection to the client:
Streaming resource:
URI uri : A GET against this URI refreshes the client representation of the resources accessible to this user.
bool WebSocket : Indicate if websocket is available on this server
bool ReverseXHR : Indicate if ReverseXHR is available on this server
bool HiddenIframe : Indicate if HiddenIframe is available on this server
Registration[] Registrations : The set of registration tasks.
OpenChannel : Open streaming channel from webserver to client. GET parameter type=(websocket|xhr|hiddeniframe)
CloseChannel : Close streaming channel from webserver to client. GET parameter type=(websocket|xhr|hiddeniframe)
A call of openchannel?type=websocket would open the websocket and start streaming the data of the registered values.
I've read many articles but I am still a bit confused. Can I still call my API REST after doing this? And if no (or yes) why?
Thank you for your help!
Firstly, always implement what makes sense to solve the problem you face. Conforming to a given architectural style provides specific benefits but this should not exclude pragmatic solutions to a given problem.
But having said that, it seems like you're using streaming of resource data as a way to "tunnel" information back & forth between the client and the server. I'm pretty new to this but it seems to me that the tunneling data goes against the uniform interface constraint in the REST architectural style. Tunneling over HTTP is one of criticism level against soap based services.