x6351.htm

Its a xmpp protocol book

>-&#62;</TT
>
IQ set <TT
CLASS="LITERAL"
>-&#62;</TT
>
IQ result. 
This pattern isn't any different here, but it's not essential. Bearing 
in mind that registration field requirements aren't going to change 
that often, and even if they do, the only ones that are enforced are 
<TT
CLASS="LITERAL"
>&#60;username/&#62;</TT
> and 
<TT
CLASS="LITERAL"
>&#60;password/&#62;</TT
>, you can get away with 
forgoing the IQ get and cutting straight to the chase with an IQ set. 
This isn't a recommendation to do that, merely an observation,
as it's always good practise to "ask first".</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-6-SECT-5.2.2.5"
>Still No Connection</A
></H3
><P
>After registering a new user, note that there's still no session. Only 
after successful authorization (see later in this Chapter) is a session
created. Although used in authentication (and so implicitly in session
creation), the value of the <TT
CLASS="LITERAL"
>id</TT
> attribute in the XML stream
header returned by the server (which has the value '3B2DB1A7' in 
<A
HREF="x6351.htm#JABTDG-CH-6-EX-1"
>Example 6-1</A
>) is a <I
CLASS="EMPHASIS"
>connection</I
>
id, not a <I
CLASS="EMPHASIS"
>session</I
> id.</P
><P
>So, what can we do at this stage? Well, one of two things. Register another
user (yes!) or proceed to the authentication stage. Basically, reaching
the end of the registration process, we're back where we started - a 'raw'
connection where only one of two sequences are valid - the 
<TT
CLASS="LITERAL"
>jabber:iq:register</TT
> or <TT
CLASS="LITERAL"
>jabber:iq:auth</TT
>
sequences.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-6-SECT-5.2.2.6"
>Passwords</A
></H3
><P
>You may be wondering about the plaintext nature of the password sent in
the registration process. Although the Jabber server offers different
types of password-based authentication,
there's a 'bootstrap' process required to get the password to
the server in the first place. There's no way round the fact that the
server must at one time receive the password in all its plaintext glory.
After receiving it, there are authentication processes that don't 
use the plaintext password again. </P
><P
>So if you're concerned about the security of this registration phase,
consider doing it over a secure (SSL) connection to the server. </P
><P
>We will look at the detail of the different authentication mechanisms
later in this Chapter; however it is worth noting here, in the context
of the registration process, that the JSM modules that implement the
mechanism are responsible for storing the password when it's received.
The <TT
CLASS="LITERAL"
>mod_register</TT
> module actually 'registers' the
user, but it is the <TT
CLASS="LITERAL"
>mod_auth_plain</TT
> and 
<TT
CLASS="LITERAL"
>mod_auth_0k</TT
> modules that actually store the password
when received. 

<A
NAME="AEN6492"
HREF="#FTN.AEN6492"
>[3]</A
>&#13;</P
><P
>There's another occasion where passwords are stored, and that is when
a user wishes to <I
CLASS="EMPHASIS"
>change</I
> their password. This procedure
is also covered by the <TT
CLASS="LITERAL"
>jabber:iq:register</TT
> namespace,
albeit in a different context - the context of a <I
CLASS="EMPHASIS"
>session</I
>.
While a <TT
CLASS="LITERAL"
>jabber:iq:register</TT
>-based IQ conversation outside
the context of a session is for registering a user, a similar conversation
<I
CLASS="EMPHASIS"
>within</I
> the context of a session, that is, after a
user has authenticated, is used to change the user's password. Among other
reasons, this is for security - a session context implies the user has
identified and authenticated himself, and so has the authority to change
the password.</P
><P
><A
HREF="x6351.htm#JABTDG-CH-6-EX-2"
>Example 6-2</A
> shows a typical IQ set to change a 
password.</P
><DIV
CLASS="EXAMPLE"
><A
NAME="JABTDG-CH-6-EX-2"
></A
><P
><B
>Example 6-2. Changing a password with <TT
CLASS="LITERAL"
>jabber:iq:register</TT
></B
></P
><P
><PRE
CLASS="SCREEN"
>SEND: &#60;iq type='set' id='pass_4' to='yak'&#62;
        &#60;query xmlns='jabber:iq:register'&#62;
          &#60;password&#62;newsecret&#60;/password&#62;
        &#60;/query&#62;
      &#60;/iq&#62;

RECV: &#60;iq type='result' id='pass_4' from='yak' to='dj@yak/Work'/&#62;</PRE
></P
></DIV
><P
>The <TT
CLASS="LITERAL"
>to</TT
> attribute is required here, to make sure the
query is handled by the server itself. We can also see evidence that the
context of this exchange is within a session in the value of the 
<TT
CLASS="LITERAL"
>to</TT
> attribute on the IQ result packet - the JID
'<TT
CLASS="LITERAL"
>dj@yak/Work</TT
>' includes a resource suffix, which implies
a session (a resource must be specified in the authentication process - see
later in this Chapter). And the specification of a
<TT
CLASS="LITERAL"
>&#60;username/&#62;</TT
> is not necessary, as the
server will stamp the incoming IQ set anyway with the JID associated
with the user's session.</P
><P
>If you had made an IQ get, as recommended above, before doing the IQ set
to change the password, the result would have looked like this:</P
><P
><PRE
CLASS="SCREEN"
>RECV: &#60;iq type='result' to='dj@yak/Work' id='pass_2' from='yak'&#62;
        &#60;query xmlns='jabber:iq:register'&#62;
          &#60;password/&#62;
          &#60;instructions&#62;
            Choose a username and password to register with this server.
          &#60;/instructions&#62;
          &#60;name/&#62;
          &#60;email/&#62;
          &#60;key&#62;9a6957b7f69535274afa5c134fb4d916c5d5c20b&#60;/key&#62;
          &#60;registered/&#62;
        &#60;/query&#62;
      &#60;/iq&#62;</PRE
></P
><P
>We see that, as in the registration IQ get outside the session context,
the contents of the <TT
CLASS="LITERAL"
>&#60;register/&#62;</TT
> section
of the JSM instance's configuration have been inserted (the 
<TT
CLASS="LITERAL"
>&#60;instructions/&#62;</TT
>, 
<TT
CLASS="LITERAL"
>&#60;name/&#62;</TT
> and
<TT
CLASS="LITERAL"
>&#60;email/&#62;</TT
> tags). Additionally, we have
a <TT
CLASS="LITERAL"
>&#60;key/&#62;</TT
> tag, as a simple security token
as described in <A
HREF="x4089.htm#JABTDG-CH-5-SECT-5.4.3.2"
>the section called <I
>IQ Subelements</I
> in Chapter 5</A
>, and a 
<TT
CLASS="LITERAL"
>&#60;registered/&#62;</TT
> tag. The 
<TT
CLASS="LITERAL"
>&#60;key/&#62;</TT
> is not actually checked in the
current implementation, and is therefore not necessary to supply in
the return IQ set packet. And the 
<TT
CLASS="LITERAL"
>&#60;register/&#62;</TT
> tag is merely a flag telling
us that the user is already registered.</P
><P
>Use of the <TT
CLASS="LITERAL"
>jabber:iq:register</TT
> namespace in conversation
with the JSM in a session context is not limited to changing passwords;
you can modify the rest of the registration details supplied when the
user was created - in this case, the <TT
CLASS="LITERAL"
>&#60;name/&#62;</TT
>
and <TT
CLASS="LITERAL"
>&#60;email/&#62;</TT
> information. In fact, with the
current implementation, because of the lack of checks, you can specify
your own fields in the <TT
CLASS="LITERAL"
>jabber:iq:register</TT
> IQ set, 
in both contexts. But don't do it; it's a habit that will probably be
impossible to keep up in later releases of the server.

<A
NAME="AEN6532"
HREF="#FTN.AEN6532"
>[4]</A
>&#13;</P
><P
>It almost goes without saying that because IQs in the
<TT
CLASS="LITERAL"
>jabber:iq:register</TT
> namespace are handled differently
in a session context, you can't register a new user once your session 
has started; you must end it. To end it, the XML stream must be closed
with a <TT
CLASS="LITERAL"
>&#60;/stream:stream&#62;</TT
>, and a new connection
and stream must then be created.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-6-SECT-5.2.2.7"
>Reversing a User Registration</A
></H3
><P
>The opposite of registering a user is <I
CLASS="EMPHASIS"
>un</I
>registering
a user. This is not the same as removing that user altogether. When the
<TT
CLASS="LITERAL"
>&#60;remove/&#62;</TT
> tag, described in
<A
HREF="x5334.htm#JABTDG-CH-5A-SECT-2.11"
>the section called <I
><TT
CLASS="LITERAL"
>jabber:iq:register</TT
></I
> in Chapter 5a</A
>, is used in a
<TT
CLASS="LITERAL"
>jabber:iq:register</TT
> qualified IQ set during a user
session, the user is <I
CLASS="EMPHASIS"
>unregistered</I
>. That is, 
all the information held in the user's spool file is removed. But the 
spool file itself is not removed until the Jabber server is shut down.
This means that even if you <TT
CLASS="LITERAL"
>&#60;remove/&#62;</TT
>
a user, the username will still exist until the server is cycled, causing
an error if the same username is used in a new registration attempt:</P
><P
><PRE
CLASS="SCREEN"
>RECV: &#60;iq type='error'&#62;
        &#60;query xmlns='jabber:iq:register'&#62;
          &#60;username&#62;dj&#60;/username&#62;
          &#60;password&#62;secret&#60;/password&#62;
        &#60;/query&#62;
        &#60;error code='409'&#62;Username Not Available&#60;/error&#62;
      &#60;/iq&#62;</PRE
></P
><P
>This may well be fixed in a later release of the Jabber server.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-6-SECT-5.2.2.8"
>A Note On Error Messages</A
></H3
><P
>There are various errors that can occur during user registration. They
are on the whole fairly plain and easy to understand. But because of the
way the server has been written, you might be surprised at 
<I
CLASS="EMPHASIS"
>what</I
> error message you receive in certain circumstances.</P
><P
>Because the required fields <TT
CLASS="LITERAL"
>&#60;username/&#62;</TT
>
and <TT
CLASS="LITERAL"
>&#60;password/&#62;</TT
> are checked
<I
CLASS="EMPHASIS"
>before</I
> looking
to see whether or not there is a <TT
CLASS="LITERAL"
>&#60;register/&#62;</TT
>
section in the JSM instance configuration, you will always receive a
<I
CLASS="EMPHASIS"
>406 'Not Acceptable'</I
> instead of a 
<I
CLASS="EMPHASIS"
>501 'Not Implemented'</I
> if you don't supply those
fields.</P
><P
>Likewise, if you specify a username that already exists, you will receive
a <I
CLASS="EMPHASIS"
>409 'Username Not Available'</I
> instead of a
<I
CLASS="EMPHASIS"
>501 'Not Implemented'</I
>. </P
><P
>Of course, if you do an IQ get with the 
<TT
CLASS="LITERAL"
>jabber:iq:register</TT
> namespace beforehand, you 
<I
CLASS="EMPHASIS"
>will</I
> receive the 'correct' error - good practise pays!</P
></DIV
></DIV
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN6412"
HREF="x6351.htm#AEN6412"
>[1]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>This may not seem like a big deal, but when you're testing against
a Jabber server using <B
CLASS="COMMAND"
>telnet</B
>, it's 20 less characters
that you have to type every time you create a new connection ;-)</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN6420"
HREF="x6351.htm#AEN6420"
>[2]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>The name 'etherx' comes from an old library that implemented XML streams.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN6492"
HREF="x6351.htm#AEN6492"
>[3]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>The <TT
CLASS="LITERAL"
>mod_auth_digest</TT
> module doesn't play a
password-storing role, as the mechanism it provides uses the plaintext
password that is stored by <TT
CLASS="LITERAL"
>mod_auth_plain</TT
></P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN6532"
HREF="x6351.htm#AEN6532"
>[4]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>And no, you can't spoof someone else by specifying the 
<TT
CLASS="LITERAL"
>&#60;username/&#62;</TT
> tag in a session context
<TT
CLASS="LITERAL"
>jabber:iq:register</TT
> IQ set; it is ignored, the correct
JID being taken from the <TT
CLASS="LITERAL"
>from</TT
> attribute stamp made
as the packet hits the server.</P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x6334.htm"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="book1.htm"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x6569.htm"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>XML Stream Flow</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="c6313.htm"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>User Authentication</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>