I was expecting to find much more information on CardDAV on the web, but unfortunatly I just don't get it.
The rfc6352 states in 1-1 that a server must understand and make Address data server side searchable, but I don't know how to do it.
Could anybody give me a hint on ressources, on how to find out what I can send how to the server?
For starters I would like to:
Connect with a user/paasword (Auth basic) to a CardDAV server
Get the Addressbooks the user has access to and their hirarchy position
For each address book get its entries (reduced to first/last name, numbers + types)
What I'm planning to do is build a gateway for Grandstream phones, which is accessable via https and returns a generated phonebook XML.
Might be usefull to add, that I want to run against kopano/sabre-dav.
Related
I'm working on a messenger app whose server side code is developed in Erlang.
The problem which I'm facing is regarding redirection of website according to country specific domain.
For example: when user's types google.co in message box, it automatically displays google.co.uk, how can I redirect it to google.co.in if I'm in India?
For finding country's location, I found this library on github: https://github.com/mochi/egeoip
How can I use this geoLocation for redirecting to particular country specific website?
ScreenShot, when I entered facebook.com, it automatically displays preview in my local language.
But in case of my app, it shows preview in some foreign language, russian maybe.
I've read the comments, and since you are not considering having datasets as an option, I think what you may want to do is something like this:
First thing to understand is how those previews work. In any (popular) messaging app, if you type in a URL, the app will send a request to the URL and get the website metadata. Then it will be displayed in the UI.
The country detection, is a bit more complicated and done in a variety of ways. But thankfully, you (almost) don't have to do anything. This is a rather long topic, but I'll try to shorten it out.
Text Localization
In some websites (might be the case of Facebook's in your example), they do country detection on the application layer, and then based on that country, it will use a specific language for the website's text. This all usually happens before the website renders it's content, so you do not have to worry about it.
GeoDNS
This one occurs on the DNS layer, and probably the most popular. Domain names can be assigned a handful of IP addresses. These IPs can point to different versions of the website, and in the case of GeoDNS it will be up to the DNS manager to assign a country to an IP. So when a DNS query came from Russia, the requesting IP's country will be resolved and then the IP assigned to it (if any) will be returned. This is used by websites especially for country-specific features or content. Best example is Netflix.
Redirects
In case of Google redirecting you to a different domain, this might be how they do it. Country is being resolved via the IP address in the application (HTTP) layer, and then does a 301/302 redirect, pointing to the new domain name. This one, you may need to do something on. So given that your application needs to do an HTTP request to the URL the user has entered, if it returns a redirect, you must follow it. Many HTTP libs/clients already does this, but on some you might have to explicitly turn on the option to follow redirects.
One important thing to note is to do the HTTP request on the client side. Otherwise, you will be resolving to the same country (where your server resides) regardless of where your user is.
I'm developing my first iPhone app to make what is effectively an app version of a fantasy league I created for work colleagues.
I am using Parse for the backend of the app. I only want people to be able to register with their work email address ie only if their e-mail address is _#mycompany.com
I'm sure this would be quite easy to someone who knew what htey were doing but I'm kind of new to this so any advice would be much appreciated.
Thanks
You could do this in a number of ways. The easiest way would be to have the validation happen on-device - just check the e-mail address the user has put into the app, and only allow the registration to happen if it matches the domain you want to limit it to.
However, although this is very easy it's also open to abuse and it's not very flexible (if you want to add additional domains, you have to update the app).
Fortunately, Parse offers cloud code, which lets you validate data server-side. Cloud code is written in JavaScript, and you then upload it to Parse. There is full documentation on Parse's website, including examples for validating data.
First of all, I'd like to provide some background information: I want to exchange unstructured data between various clients using XMPP. Data sources are supposed to publish their data simply to Mulit-User-Chat rooms (XEP-0045) so that any interested client can register.
XMPP MUC services can have various chat rooms and in order to find the ones my data sources push information to, I'd like to set some custom identification for that room. I figured muc#roominfo_<custom_ident> with some custom value would be great to accomplish that.
For testing purposes I wrote an application that creates a MUC on an XMPP service. Authentication etc. all works fine. I am using Smack to communicate with the XMPP server and to create the room. When I create the room, I am adding a field to the form field I requested before containing my custom information. The MUC is created and accessible. Yet the created custom field is not returned when I perform a disco#info on the room's JID.
I tested this with a local installation of (3.8.2).
I just wonder, if this is an issue of Openfire, that custom form fields (XEP-0068 used here in XEP-0045) are not stored when the MUC is created or if it is just not allowed according to XEP-0045? I read the specification for MUCs and crucially the respective section but couldn't find any evidence that convinced me, that it is explicitly not possible to create such custom form fields for a MUC.
Maybe I just misunderstand something in the specification? Has anyone tried something similar and it's working? If it is an issue of Openfire, I could try a different XMPP server.
I need to know if an installation has been paid for in the past so I can provide some premium features.
Storing a payment flag in indexeddb or the file system sounds easy to defeat. Periodically asking a server and caching the response could do the trick, but I guess the user would have to be logged-in at all times (through google or otherwise) and I'd rather not impose that restriction.
Maybe if there's a way to uniquely identify a user's machine (uuid, mac address, etc) that could allow me to determine if they've made that payment?
Ultimately, this is client side JavaScript. The only means by which you can prevent use of certain features, is to put them on your server and charge for the service.
Some weak methods for preventing access include license validation, and asking the server for non-essential information (if it was essential, then see the above).
For license validation, you could create an algorithm that takes data from the user and transforms it into something else. For example, say they create an account on your website, which your server knows is a 'pro' account. You could then take their first name and email address and do some magic on it.
Here's a simple example that takes those inputs and gives us a key. In this example if our first name is "John" and our email is "john#domain.org", then our key will be fcumnflqjpBfqockp0qtifcufLqjp. However, Tony, with the email "tony#doman.org" would recieve fcumnfvqp{Bfqockp0qtifcufVqp{
You can send this key to the user, and have your code decide whether it can extract the name and email by applying the reverse algorithm.
You can reverse the strings, do various bit math, etc. It's security by obscurity. Other than an account, this is the most common method. It's used by nearly all offline software. Its kryptonite is key generators, which reverse engineer your code, and generate keys by the algorithm you use to verify them.
All the methods such as uuid, mac address etc can be easily forged imo. I think you cannot escape keeping track of user's logged-in status. Implementing something like a cookie based mechanism would be the right way to go.
I have got an Openfire Jabber server with in excess of 75,000 users listed. Of those, 150 or more can be online at any one time.
Is there anywhere that I can collect the JIDs (usernames) of the currently logged in users? I have full database access to the underlying data, but the server does not appear to write the current status back to the DB. Because of the number of users, rosters are not being used.
A very useful set of data being returned would be from a simple (password protected) webpage with one JID per line, optionally with the login time, and maybe also the last time that account performed an action [like send a message]. The latter two are not as essential, but would be useful if the data is available, as well as any other information that was available regarding the user session.
dont know if this will help but I ran into it looking for similar functionality. As defined in XEP-0045 http://xmpp.org/extensions/xep-0045.html#disco-roominfo :
An implementation MAY return a list of existing occupants if that information is publicly
available, or return no list at all if this information is kept private. Implementations
and deployments are advised to turn off such information sharing by default.
So you would need to ensure it works as advertised on Openfire (all xmpp servers ive come across have a bug or two in them), and I imagine you would need to code some logic to get the results.
Good luck.
Not a perfect answer, but the query you want is probably embedded in the session-summary.jsp page. I got to it on a locally hosted server at http://localhost:9090/session-summary.jsp. What I don't know is if that is then stored in the database where it is query-able, or if it is stored internally to the client. The latter is more likely.
The data that page displays is Name, Resource, Status, Presence, Priority, Client IP, and Close Connection.