I was asked to develop a web-application that can talk to my company's Card-/CalDAV-Server (Kerio Connect). I've spent the past hours trying to find a suitable library but there doesn't seem to be one that is functional and still maintained. Milton looks great, but it's written in JAVA, which neither I nor my co-workers have worked with.
Instead, I'll probably have to write something myself, preferably in PHP or JavaScript. My question is; how? I really like how the entire thing is http-based, but aside from the RFC, there's very little documentation to be found. While I did manage to get a few of my curl-requests answered, others failed without me understanding why:
curl -X PROPFIND -u username#domain.tld:password -H "Content-Type: text/xml" -H "Depth: 1" --data "<propfind xmlns='DAV:'><prop><displayname /></prop></propfind>" http://webmail.domain.tld/carddav/users/domain.tld/.public
This works. I get a response containing "Public Folders (domain.tld)", which is, well, what I asked for.
curl -X PROPFIND -u username#domain.tld:password -H "Content-Type: text/xml" -H "Depth: 1" --data "<propfind xmlns='DAV:'><prop><addressbook-home-set xmlns="urn:ietf:params:xml:ns:carddav"/></prop></propfind>" http://webmail.domain.tld/carddav/users/domain.tld/.public
This one, on the other hand, returns 403 - Forbidden.
Both requests are probably wrong in some way - they're simply what I managed to piece together.
So how can I approach this? Would it be best to just read the RFC's, top to bottom? So far, they haven't been that helpful.
Edit:
I've read both articles on sabre.io. They did help me to some extend. However, I'm still not able to get the actual contact-data. I've managed to get a summary that contains UUID's for our shared address book, but how to use those UUID's, I have no idea.
Further, neither article goes into much detail as to how things are supposed to work. For example, first the CardDAV-related article states that the ctag must be stored for subsequent requests, then, only a few lines later, it mentions that the server might not support it at all. Further down, I learn that the ctag is supposedly a tag that lets me know if something has changed on the server; This is the purpose of the ctag. Every time anything in the address book changes, the ctag must also change. So..., what happens when my server doesn't support it? How do I know if it does? Requesting it simply yields a 403 - forbidden.
This is the request I'm using;
curl -X PROPFIND -u username#domain.tld:password -H "Content-Type: text/xml" --data "<d:propfind xmlns:d="DAV:" xmlns:cs="http://calendarserver.org/ns/"><d:prop><cs:getctag /></d:prop></d:propfind>" https://domain.tld/carddav/users/domain.tld/.public/
To get the aforementioned summary of our public address book, I used;
curl -X REPORT -u username#domain.tld:password -H "Content-Type: text/xml" --data "<c:addressbook-query xmlns:d='DAV:' xmlns:c='urn:ietf:params:xml:ns:carddav'><d:prop><c:address-data></c:address-data></d:prop></c:addressbook-query>" https://domain.tld/public-contacts/domain.tld/
The SabreDAV website has a pretty good article on how to write CalDAV and CardDAV clients: Building a CalDAV client.
Besides, SabreDAV likely has a lot of the code which you would need to implement a DAV client in PHP. Other library implementations are listed on the CalConnect CalDAV website.
Related
I want to develop an action to google assistant. So i red the documentation here https://developers.google.com/assistant/conversational/overview and i followed this tutorial https://www.youtube.com/watch?v=Z1hxvniJ18s
It s worked and i was allow to develop and test my app in the simulator. The problem is that when it's come to webhook i don't totaly understand how it's work. On the webhook icon i got this
The seconde one allow me to use Google cloud function and firebase but i had to add my billing account to make it available. I also get a console where i can code my fonctions and my responses.
And if i am correct, the first one allow me to connect to my own Api. But i can only enter one field that is the URL adresse and nothing else so how do i code it? Also i see everywhere people using node.js and i would like to use php is it possible?
To sum up my problem, i would like to know how i could connect my action builder to an other service(Api) than google ones? If it's possible to run my server in php and how do i interact with my google action?(I think it's by sending json back and forth but i'am not sure how to do it?) Finally i would like to know if it's possible to test it in local server with mamp and phpmyadmin for exemple to test the answer of the server?
I would be very grateful if someone could help me, show me how to set up all this.
But i can only enter one field that is the URL adresse and nothing else so how do i code it?
When you develop your webhook, you will need to have a single publicly accessible endpoint to connect with. This endpoint will receive an HTTP POST request and you will need to respond with an appropriate response.
Also i see everywhere people using node.js and i would like to use php is it possible?
Any language that can run on a web server can work. Node.js is one that is used a lot, but PHP can work just as well. You can create an actions.php file and then enter an endpoint address https://example.com/actions.php that will be called. You may need to refer to the Request and Response reference for the expected format.
if it's possible to test it in local server with mamp and phpmyadmin for exemple to test the answer of the server?
It's somewhat possible. You'll need to have some method of sending mock requests to your local server, which might be as easy as using cURL or other tools like Postman.
Unfortunately my personal experience with PHP tools is limited, so I can't necessarily walk-through the specifics. But it does seem like you know these tools a bit more and should be familiar enough to be able to get started.
Is it possible to issue a redirect to a rtmp request - similar to a http 302 redirect?
It is not possible for me to fix all of the rtmp urls that exist in my content, so I would like to put some sort of a basic redirector in place that will send requests to my new server.
Thanks!
I haven't understood you completely but I think I can help you a little bit and go on clarifying with comments. For example, I don't know if you have different entry points or just distribute 1->N.
Your proposal, if I didn't misunderstand, is that you have an RTMP
traffic as input of a basic redirector, and wants to send the same
content to a list of RTMP addresses placed for example in a text file.
Your question is how to implement this basic redirector, isn't it?
In that case, you could do it with FFmpeg application, in the same way streaming systems send data to multi-publishing points (CDN for distribution)
File: rtmp_output_list.txt
rtmp://001.entrypoint.your_cloud.com/live/your_name?user=your_user&pass=your_pass
rtmp://002.entrypoint.your_cloud.com/live/your_name?user=your_user&pass=your_pass
rtmp://003.entrypoint.your_cloud.com/live/another_name?user=another_user&pass=another_pass
...
Bash script calling ffmpeg: basic_redirector.sh
#!/bin/bash for RTMP_OUTPUT in `cat rtmp_output_list.txt`
RTMP_INPUT="rtmp://192.168.0.101/test"
METADATA="-metadata width=XXX -metadata height=XXX ... [rest of metadata]"
do
ffmpeg -i $RTMP_INPUT -async 1 -vcodec copy -acodec copy $METADATA -f megts -f flv $RTMP_OUTPUT
done
If I didn't understand you correctly, please, comment and I'll help you.
Good luck.
There is no such concept in RTMP. You will need the client to connect to an endpoint to query what URL to broadcast to.
I am trying to use this api documentation to send Tinder messages (etc) via the Linux command line. Unfortunately, I can't even get past the authentication step. I follow the directions as best I can (getting my facebook id off of this site). I end up with a command similar to the following:
> curl -X POST https://api.gotinder.com/auth --data '{"facebook_token":"LETTERSandSTUFF", "facebook_id":"allnumbers"}'
I've tried a couple variations of this as well, but no matter what, I get back the same result:
{"code":401,"error":"FacebookTokenRequired"}
I also tried to use mitmproxy to learn more about what Tinder and other programs were actually doing. However, even though mitmproxy was recording my computer accurately, when I tried to proxy my phone through mitmproxy's port, it ceased to load anything (it would time out).
Mostly I would just like to be able to send messages on Tinder somehow, but if anybody has any idea why mitmproxy isn't working, that would be very helpful.
First time posting a question. I'm trying to call some SOAP webservices from inside a blackberry app using the ksoap2 library. I've successfully managed to get a response from the one service, which uses an HTTP url, but now that I'm trying to get response from a (different) HTTPS url, I've run up against a brick wall.
The response dump I'm getting has the following fault message:
"An error occurred while routing the message for element value : (country option I specified in my request). Keep-Alive and Close may not be set using this property. Parameter name: value."
The weird thing is that using Oxygen XML's SOAP tools with the XML request dump works just fine. Any ideas where to start looking? This has taken up a full day already.
Update:
Responding to your comment below - it turns out the double quoting is part of the SOAP spec. Some servers are more relaxed in their implementation, and will work without the quotes.
ksoap2 doesn't force the quotes onto your actions - you may want to patch your ksoap2 library to ensure the quotes are always there.
ymmv
Original:
I don't think this is a SOAP related problem, nor with BlackBerry.
I think the problem lies on the server side, since that error string is not a common error (just google it to see no hits on the whole internet other than this question).
Looks like this is a job for the network guy on the server side to tell you what he's seeing on his end.
Only other thing I can think of is to make the call using HTTP instead of HTTPS. You can then use some network sniffer to see what the difference between the messages is. Alternatively, install an SSL proxy with something like "Charles" and sniff the packets like that.
I'm trying to develop a simple REST API. I'm still trying to understand the basic architectural paradigms for it. I need some help with the following:
"Resources" should be nouns, right? So, I should have "user", not "getUser", right?
I've seen this approach in some APIs: www.domain.com/users/ (returns list), www.domain.com/users/user (do something specific to a user). Is this approach good?
In most examples I've seen, the input and output values are usually just name/value pairs (e.g. color='red'). What if I wanted to send or return something more complex than that? Am I forced to deal with XML only?
Assume a PUT to /user/ method to add a new user to the system. What would be a good format for input parameter (assume the only fields needed are 'username' and 'password')? What would be a good response if the user is successful? What if the user has failed (and I want to return a descriptive error message)?
What is a good & simple approach to authentication & authorization? I'd like to restrict most of the methods to users who have "logged in" successfully. Is passing username/password at each call OK? Is passing a token considered more secured (if so, how should this be implemented in terms of expiration, etc.)?
For point 1, yes. Nouns are expected.
For point 2, I'd expect /users to give me a list of users. I'd expect /users/123 to give me a particular user.
For point 3, you can return anything. Your client can specify what it wants. e.g. text/xml, application/json etc. by using an HTTP request header, and you should comply as much as you can with that request (although you may only handle, say, text/xml - that would be reasonable in a lot of situations).
For point 4, I'd expect POST to create a new user. PUT would update an existing object. For reporting success or errors, you should be using the existing HTTP success/error codes. e.g. 200 OK. See this SO answer for more info.
the most important constraint of REST is the hypermedia constraint ("hypertext as the engine of application state"). Think of your Web application as a state machine where each state can be requested by the client (e.g. GET /user/1).Once the client has one such state (think: a user looking at a Web page) it sees a bunch of links that it can follow to go to a next state in the application. For example, there might be a link from the 'user state' that the client can follow to go to the details state.
This way, the server presents the client the application's state machine one state at a time at runtime. The clever thing: since the state machine is discovered at runtime on state at a time, the server can dynamically change the state machine at runtime.
Having said that...
on 1. the resources essentially represent the application states you want to present to the client. The will often closely match domain objects (e.g. user) but make sure you understand that the representations you provide for them are not simply serialized domain objects but states of your Web application.
Thinking in terms of GET /users/123 is fine. Do NOT place any action inside a URI. Although not harmful (it is just an opaque string) it is confusing to say the least.
on 2. As Brian said. You might want to take a look at the Atom Publishing Protocol RFC (5023) because it explains create/read/update cycles pretty well.
on 3. Focus on document oriented messages. Media types are an essential part of REST because they provide the application semantics (completely). Do not use generic types such as application/xml or application/json as you'll couple your clients and servers around the often implicit schema. If nothing fits your needs, just make up your own type.
Maybe you are interested in an example I am hacking together using UBL: http://www.nordsc.com/blog/?cat=13
on 4. Normally, use POST /users/ for creation. Have a look at RFC 5023 - this will clarify that. It is an easy to understand spec.
on 5. Since you cannot use sessions (stateful server) and be RESTful you have to send credentials in every request. Various HTTP auth schemes handle that already. It is also important with regard to caching because the HTTP Authorization header has special specified semantics to caches (no public caching). If you stuff your credentials into a cookie, you loose that important piece.
All HTTP status codes have a certain application semantic. Use them, do not tunnel your own error semantics through HTTP.
You can come visit #rest IRC or join rest-discuss on Yahoo for detailed discussions.
Jan