Note that gnutls is picky in regard to what it accepts as the server name - it
MUST be a domain name. IP addresses are not supported according to the
documentation.
Hence, filter out IP addresses and hope that whatever is not recognized as
such an address is actually a domain name. This will probably fail for more
exotic addresses (especially in IPv6 realm), but wiring up a full-blown parser
is too much effort and SSL plugins are not part of purple-3 anyway.
Fixes #17300
/*
* purple
*
* Purple is the legal property of its developers, whose names are too numerous
* to list here. Please refer to the COPYRIGHT file distributed with this
* source distribution.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02111-1301 USA
*/
#ifndef _PURPLE_STATUS_H_
#define _PURPLE_STATUS_H_
/**
* @file status.h Status API
* @ingroup core
*
* A brief explanation of the status API:
*
* PurpleStatusType's are created by each PRPL. They outline the
* available statuses of the protocol. AIM, for example, supports
* an available state with an optional available message, an away
* state with a mandatory message, and an invisible state (which is
* technically "independent" of the other two, but we'll get into
* that later). PurpleStatusTypes are very permanent. They are
* hardcoded in each PRPL and will not change often. And because
* they are hardcoded, they do not need to be saved to any XML file.
*
* A PurpleStatus can be thought of as an "instance" of a PurpleStatusType.
* If you're familiar with object-oriented programming languages
* then this should be immediately clear. Say, for example, that
* one of your AIM buddies has set himself as "away." You have a
* PurpleBuddy node for this person in your buddy list. Purple wants
* to mark this buddy as "away," so it creates a new PurpleStatus.
* The PurpleStatus has its PurpleStatusType set to the "away" state
* for the oscar PRPL. The PurpleStatus also contains the buddy's
* away message. PurpleStatuses are sometimes saved, depending on
* the context. The current PurpleStatuses associated with each of
* your accounts are saved so that the next time you start Purple,
* your accounts will be set to their last known statuses. There
* is also a list of saved statuses that are written to the
* status.xml file. Also, each PurpleStatus has a "saveable" boolean.
* If "saveable" is set to FALSE then the status is NEVER saved.
* All PurpleStatuses should be inside a PurplePresence.
*
*
* A PurpleStatus is either "independent" or "exclusive."
* Independent statuses can be active or inactive and they don't
* affect anything else. However, you can only have one exclusive
* status per PurplePresence. If you activate one exclusive status,
* then the previous exclusive status is automatically deactivated.
*
* A PurplePresence is like a collection of PurpleStatuses (plus some
* other random info). For any buddy, or for any one of your accounts,
* or for any person with which you're chatting, you may know various
* amounts of information. This information is all contained in
* one PurplePresence. If one of your buddies is away and idle,
* then the presence contains the PurpleStatus for their awayness,
* and it contains their current idle time. PurplePresences are
* never saved to disk. The information they contain is only relevant
* for the current PurpleSession.
*/
/**
* PurpleStatusType's are created by each PRPL. They outline the
* available statuses of the protocol. AIM, for example, supports
* an available state with an optional available message, an away
* state with a mandatory message, and an invisible state (which is
* technically "independent" of the other two, but we'll get into
* that later). PurpleStatusTypes are very permanent. They are
* hardcoded in each PRPL and will not change often. And because
* they are hardcoded, they do not need to be saved to any XML file.
*/
typedefstruct_PurpleStatusTypePurpleStatusType;
typedefstruct_PurpleStatusAttrPurpleStatusAttr;
typedefstruct_PurplePresencePurplePresence;
typedefstruct_PurpleStatusPurpleStatus;
typedefstruct_PurpleMood{
constchar*mood;
constchar*description;
gpointer*padding;
}PurpleMood;
/**
* A context for a presence.
*
* The context indicates to what the presence applies.
*/
typedefenum
{
PURPLE_PRESENCE_CONTEXT_UNSET=0,
PURPLE_PRESENCE_CONTEXT_ACCOUNT,
PURPLE_PRESENCE_CONTEXT_CONV,
PURPLE_PRESENCE_CONTEXT_BUDDY
}PurplePresenceContext;
/**
* A primitive defining the basic structure of a status type.
*/
/*
* If you add a value to this enum, make sure you update
* the status_primitive_map and primitive_scores arrays in status.c.