~justin-fathomdb/nova/justinsb-openstack-api-volumes

<?xml version="1.0" encoding="utf-8"?><!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'><html lang="en" xmlns="http://www.w3.org/1999/xhtml">

<head>

<title>Twisted Documentation: Authentication with Perspective Broker</title>

</head>

<h1 class="title">Authentication with Perspective Broker</h1>

<div class="toc"><ol><li><a href="#auto0">Overview</a></li><li><a href="#auto1">Compartmentalizing Services</a></li><ul><li><a href="#auto2">Incorrect Arguments</a></li><li><a href="#auto3">Unforgeable References</a></li><li><a href="#auto4">Argument Typechecking</a></li><li><a href="#auto5">Objects as Capabilities</a></li></ul><li><a href="#auto6">Avatars and Perspectives</a></li><li><a href="#auto7">Perspective Examples</a></li><ul><li><a href="#auto8">One Client</a></li><li><a href="#auto9">Two Clients</a></li><li><a href="#auto10">How that example worked</a></li><li><a href="#auto11">Anonymous Clients</a></li></ul><li><a href="#auto12">Using Avatars</a></li><ul><li><a href="#auto13">Avatar Interfaces</a></li><li><a href="#auto14">Logging Out</a></li><li><a href="#auto15">Making Avatars</a></li><li><a href="#auto16">Connecting and Disconnecting</a></li><li><a href="#auto17">Viewable</a></li><li><a href="#auto18">Chat Server with Avatars</a></li></ul></ol></div>

<h2>Overview<a name="auto0"/></h2>

The examples shown in <a href="pb-usage.html" shape="rect">Using Perspective

Broker</a> demonstrate how to do basic remote method calls, but provided no

facilities for authentication. In this context, authentication is about who

gets which remote references, and how to restrict access to the <q>right</q>

set of people or programs.

As soon as you have a program which offers services to multiple users,

where those users should not be allowed to interfere with each other, you

need to think about authentication. Many services use the idea of an

<q>account</q>, and rely upon fact that each user has access to only one

account. Twisted uses a system called <a href="cred.html" shape="rect">cred</a> to

handle authentication issues, and Perspective Broker has code to make it

easy to implement the most common use cases.

<h2>Compartmentalizing Services<a name="auto1"/></h2>

Imagine how you would write a chat server using PB. The first step might

be a <code>ChatServer</code> object which had a bunch of

<code>pb.RemoteReference</code>s that point at user clients. Pretend that

those clients offered a <code>remote_print</code> method which lets the

server print a message on the user's console. In that case, the server might

look something like this:

<pre class="python"> 1

class ChatServer(pb.Referenceable):

def __init__(self):

self.groups = {} # indexed by name

self.users = {} # indexed by name

def remote_joinGroup(self, username, groupname):

if not self.groups.has_key(groupname):

self.groups[groupname] = []

self.groups[groupname].append(self.users[username])

def remote_sendMessage(self, from_username, groupname, message):

group = self.groups[groupname]

if group:

# send the message to all members of the group

for user in group:

user.callRemote("print",

"<%s> says: %s" % (from_username,

message))

</pre>

For now, assume that all clients have somehow acquired a

<code>pb.RemoteReference</code> to this <code>ChatServer</code> object,

perhaps using <code>pb.Root</code> and <code>getRootObject</code> as

described in the <a href="pb-usage.html" shape="rect">previous chapter</a>. In this

scheme, when a user sends a message to the group, their client runs

something like the following:

<pre class="python">1

remotegroup.callRemote("sendMessage", "alice", "Hi, my name is alice.")

</pre>

<h3>Incorrect Arguments<a name="auto2"/></h3>

You've probably seen the first problem: users can trivially spoof each

other. We depend upon the user to pass a correct value in their

<q>username</q> argument, and have no way to tell if they're lying or not.

There is nothing to prevent Alice from modifying her client to do:

<pre class="python">1

remotegroup.callRemote("sendMessage", "bob", "i like pork")

</pre>

much to the horror of Bob's vegetarian friends.<a href="#footnote-1" title="Apparently Alice is one of those weirdos who has nothing better to do than to try and impersonate Bob. She will lie to her chat client, send incorrect objects to remote methods, even rewrite her local client code entirely to accomplish this juvenile prank. Given this adversarial relationship, one must wonder why she and Bob seem to spend so much time together: their adventures are clearly documented by the cryptographic literature."><super>1</super></a>

(In general, learn to get suspicious if you see any argument of a

100

remotely-invokable method described as <q>must be X</q>)

101

102

The best way to fix this is to keep track of the user's name locally,

103

rather than asking them to send it to the server with each message. The best

104

place to keep state is in an object, so this suggests we need a per-user

105

object. Rather than choosing an obvious name<a href="#footnote-2" title="the obvious name is clearly ServerSidePerUserObjectWhichNobodyElseHasAccessTo, but because python makes everything else so easy to read, it only seems fair to make your audience work for something"><super>2</super></a>, let's call this the

106

<code>User</code> class.

107

108

109

<pre class="python"> 1

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

class User(pb.Referenceable):

135

def __init__(self, username, server, clientref):

136

self.name = username

137

self.server = server

138

self.remote = clientref

139

def remote_joinGroup(self, groupname):

140

self.server.joinGroup(groupname, self)

141

def remote_sendMessage(self, groupname, message):

142

self.server.sendMessage(self.name, groupname, message)

143

def send(self, message):

144

self.remote.callRemote("print", message)

145

146

class ChatServer:

147

def __init__(self):

148

self.groups = {} # indexed by name

149

def joinGroup(self, groupname, user):

150

151

self.groups[groupname] = []

152

153

def sendMessage(self, from_username, groupname, message):

154

group = self.groups[groupname]

155

if group:

156

# send the message to all members of the group

157

for user in group:

158

user.send("<%s> says: %s" % (from_username, message))

159

</pre>

160

161

Again, assume that each remote client gets access to a single

162

<code>User</code> object, which is created with the proper username.

163

164

Note how the <code>ChatServer</code> object has no remote access: it

165

isn't even <code>pb.Referenceable</code> anymore. This means that all access

166

to it must be mediated through other objects, with code that is under your

167

control.

168

169

As long as Alice only has access to her own <code>User</code> object, she

170

can no longer spoof Bob. The only way for her to invoke

171

<code>ChatServer.sendMessage</code> is to call her <code>User</code>

172

object's <code>remote_sendMessage</code> method, and that method uses its

173

own state to provide the <code>from_username</code> argument. It doesn't

174

give her any way to change that state.

175

176

This restriction is important. The <code>User</code> object is able to

177

maintain its own integrity because there is a wall between the object and

178

the client: the client cannot inspect or modify internal state, like the

179

<code>.name</code> attribute. The only way through this wall is via remote

180

method invocations, and the only control Alice has over those invocations is

181

when they get invoked and what arguments they are given.

182

183

<div class="note">Note:

184

No object can maintain its integrity against local threats: by design,

185

Python offers no mechanism for class instances to hide their attributes, and

186

once an intruder has a copy of <code>self.__dict__</code>, they can do

187

everything the original object was able to do.

188

</div>

189

190

191

<h3>Unforgeable References<a name="auto3"/></h3>

192

193

Now suppose you wanted to implement group parameters, for example a mode

194

in which nobody was allowed to talk about mattresses because some users were

195

sensitive and calming them down after someone said <q>mattress</q> is a

196

hassle that were best avoided altogether. Again, per-group state implies a

197

per-group object. We'll go out on a limb and call this the

198

<code>Group</code> object:

199

200

<pre class="python"> 1

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

class User(pb.Referenceable):

232

233

self.name = username

234

self.server = server

235

self.remote = clientref

236

def remote_joinGroup(self, groupname, allowMattress=True):

237

return self.server.joinGroup(groupname, self)

238

def send(self, message):

239

240

241

class Group(pb.Referenceable):

242

def __init__(self, groupname, allowMattress):

243

self.name = groupname

244

self.allowMattress = allowMattress

245

self.users = []

246

def remote_send(self, from_user, message):

247

if not self.allowMattress and message.find("mattress") != -1:

248

raise ValueError, "Don't say that word"

249

for user in self.users:

250

user.send("<%s> says: %s" % (from_user.name, message))

251

def addUser(self, user):

252

self.users.append(user)

253

254

class ChatServer:

255

def __init__(self):

256

self.groups = {} # indexed by name

257

258

259

self.groups[groupname] = Group(groupname, allowMattress)

260

self.groups[groupname].addUser(user)

261

return self.groups[groupname]

262

</pre>

263

264

265

This example takes advantage of the fact that

266

<code>pb.Referenceable</code> objects sent over a wire can be returned to

267

you, and they will be turned into references to the same object that you

268

originally sent. The client cannot modify the object in any way: all they

269

can do is point at it and invoke its <code>remote_*</code> methods. Thus,

270

you can be sure that the <code>.name</code> attribute remains the same as

271

you left it. In this case, the client code would look something like

272

this:

273

274

<pre class="python">1

275

276

277

278

279

280

281

282

283

class ClientThing(pb.Referenceable):

284

def remote_print(self, message):

285

print message

286

def join(self):

287

d = self.remoteUser.callRemote("joinGroup", "#twisted",

288

allowMattress=False)

289

d.addCallback(self.gotGroup)

290

def gotGroup(self, group):

291

group.callRemote("send", self.remoteUser, "hi everybody")

292

</pre>

293

294

The <code>User</code> object is sent from the server side, and is turned

295

into a <code>pb.RemoteReference</code> when it arrives at the client. The

296

client sends it back to <code>Group.remote_send</code>, and PB turns it back

297

into a reference to the original <code>User</code> when it gets there.

298

<code>Group.remote_send</code> can then use its <code>.name</code> attribute

299

as the sender of the message.

300

301

<div class="note">Note:

302

303

Third party references (there aren't any)

304

305

This technique also relies upon the fact that the

306

<code>pb.Referenceable</code> reference can only come from someone

307

who holds a corresponding <code>pb.RemoteReference</code>. The design of the

308

serialization mechanism (implemented in <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.spread.jelly.html" title="twisted.spread.jelly">twisted.spread.jelly</a></code>: pb, jelly, spread.. get it? Look for

309

<q>banana</q>, too. What other networking framework

310

can claim API names based on sandwich ingredients?) makes it impossible for

311

a client to obtain a reference that they weren't explicitly given.

312

References passed over the wire are given id numbers and recorded in a

313

per-connection dictionary. If you didn't give them the reference, the id

314

number won't be in the dict, and no amount of guessing by a malicious client

315

will give them anything else. The dict goes away when the connection is

316

dropped, further limiting the scope of those references.

317

318

Futhermore, it is not possible for Bob to send his

319

<code>User</code> reference to Alice (perhaps over some other PB channel

320

just between the two of them). Outside the context of Bob's connection to

321

the server, that reference is just a meaningless number. To prevent

322

confusion, PB will tell you if you try to give it away: when you try to hand

323

a <code>pb.RemoteReference</code> to a third party, you'll get an exception

324

(implemented with an assert in pb.py:364 RemoteReference.jellyFor).

325

326

This helps the security model somewhat: only the client you gave the

327

reference to can cause any damage with it. Of course, the client might be a

328

brainless zombie, simply doing anything some third party wants. When it's

329

not proxying <code>callRemote</code> invocations, it's probably terrorizing

330

the living and searching out human brains for sustenance. In short, if you

331

don't trust them, don't give them that reference.

332

333

And remember that everything you've ever given them over that connection

334

can come back to you. If expect the client to invoke your method with some

335

object A that you sent to them earlier, and instead they send you object B

336

(that you also sent to them earlier), and you don't check it somehow, then

337

you've just opened up a security hole (we'll see an example of this

338

shortly). It may be better to keep such objects in a dictionary on the

339

server side, and have the client send you an index string instead. Doing it

340

that way makes it obvious that they can send you anything they want, and

341

improves the chances that you'll remember to implement the right checks.

342

(This is exactly what PB is doing underneath, with a per-connection

343

dictionary of <code>Referenceable</code> objects, indexed by a number).

344

345

And, of course, you have to make sure you don't accidentally hand out a

346

reference to the wrong object.

347

348

</div>

349

350

351

But again, note the vulnerability. If Alice holds a

352

<code>RemoteReference</code> to any object on the server side that

353

has a <code>.name</code> attribute, she can use that name as a spoofed

354

<q>from</q> parameter. As a simple example, what if her client code looked

355

like:

356

357

<pre class="python">1

358

359

360

361

362

363

class ClientThing(pb.Referenceable):

364

def join(self):

365

366

d.addCallback(self.gotGroup)

367

def gotGroup(self, group):

368

group.callRemote("send", from_user=group, "hi everybody")

369

</pre>

370

371

This would let her send a message that appeared to come from

372

<q>#twisted</q> rather than <q>Alice</q>. If she joined a group that

373

happened to be named <q>bob</q> (perhaps it is the <q>How To Be Bob</q>

374

channel, populated by Alice and countless others, a place where they can

375

share stories about their best impersonating-Bob moments), then she would be

376

able to emit a message that looked like <q><bob> says: hi there</q>,

377

and she has accomplished her lifelong goal.

378

379

380

<h3>Argument Typechecking<a name="auto4"/></h3>

381

382

There are two techniques to close this hole. The first is to have your

383

remotely-invokable methods do type-checking on their arguments: if

384

<code>Group.remote_send</code> asserted <code>isinstance(from_user,

385

User)</code> then Alice couldn't use non-User objects to do her spoofing,

386

and hopefully the rest of the system is designed well enough to prevent her

387

from obtaining access to somebody else's User object.

388

389

390

<h3>Objects as Capabilities<a name="auto5"/></h3>

391

392

The second technique is to avoid having the client send you the objects

393

altogether. If they don't send you anything, there is nothing to verify. In

394

this case, you would have to have a per-user-per-group object, in which the

395

<code>remote_send</code> method would only take a single

396

<code>message</code> argument. The <code>UserGroup</code> object is created

397

with references to the only <code>User</code> and <code>Group</code> objects

398

that it will ever use, so no lookups are needed:

399

400

<pre class="python"> 1

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

class UserGroup(pb.Referenceable):

420

def __init__(self, user, group):

421

self.user = user

422

self.group = group

423

def remote_send(self, message):

424

self.group.send(self.user.name, message)

425

426

class Group:

427

def __init__(self, groupname, allowMattress):

428

self.name = groupname

429

self.allowMattress = allowMattress

430

self.users = []

431

def send(self, from_user, message):

432

433

raise ValueError, "Don't say that word"

434

435

user.send("<%s> says: %s" % (from_user.name, message))

436

def addUser(self, user):

437

self.users.append(user)

438

</pre>

439

440

The only message-sending method Alice has left is

441

<code>UserGroup.remote_send</code>, and it only accepts a message: there are

442

no remaining ways to influence the <q>from</q> name.

443

444

In this model, each remotely-accessible object represents a very small

445

set of capabilities. Security is achieved by only granting a minimal set of

446

abilities to each remote user.

447

448

PB provides a shortcut which makes this technique easier to use. The

449

<code>Viewable</code> class will be discussed <a href="#viewable" shape="rect">below</a>.

450

451

<h2>Avatars and Perspectives<a name="auto6"/></h2>

452

453

In Twisted's <a href="cred.html" shape="rect">cred</a> system, an <q>Avatar</q> is

454

an object that lives on the <q>server</q> side (defined here as the side

455

farthest from the human who is trying to get something done) which lets the

456

remote user get something done. The avatar isn't really a particular class,

457

it's more like a description of a role that some object plays, as in <q>the

458

Foo object here is acting as the user's avatar for this particular

459

service</q>. Generally, the remote user has some way of getting their avatar

460

to run some code. The avatar object may enforce some security checks, and

461

provide additional data, then call other methods which get things done.

462

463

The two pieces in the cred puzzle (for any protocol, not just PB) are:

464

<q>what serves as the Avatar?</q>, and <q>how does the user get access to

465

it?</q>.

466

467

For PB, the first question is easy. The Avatar is a remotely-accessible

468

object which can run code: this is a perfect description of

469

<code>pb.Referenceable</code> and its subclasses. We shall defer the second

470

question until the next section.

471

472

In the example above, you can think of the <code>ChatServer</code> and

473

<code>Group</code> objects as a service. The <code>User</code> object is the

474

user's server-side representative: everything the user is capable of doing

475

is done by running one of its methods. Anything that the server wants to do

476

to the user (change their group membership, change their name, delete their

477

pet cat, whatever) is done by manipulating the <code>User</code> object.

478

479

There are multiple User objects living in peace and harmony around the

480

ChatServer. Each has a different point of view on the services provided by

481

the ChatServer and the Groups: each may belong to different groups, some

482

might have more permissions than others (like the ability to create groups).

483

These different points of view are called <q>Perspectives</q>. This is the

484

origin of the term <q>Perspective</q> in <q>Perspective Broker</q>: PB

485

provides and controls (i.e. <q>brokers</q>) access to Perspectives.

486

487

Once upon a time, these local-representative objects were actually called

488

<code>pb.Perspective</code>. But this has changed with the advent of the

489

rewritten cred system, and now the more generic term for a local

490

representative object is an Avatar. But you will still see reference to

491

<q>Perspective</q> in the code, the docs, and the module names<a href="#footnote-3" title="We could just go ahead and rename Perspective Broker to be Avatar Broker, but 1) that would cause massive compatibility problems, and 2) AB doesn't fit into the whole sandwich-themed naming scheme nearly as well as PB does. If we changed it to AB, we'd probably have to change Banana to be CD (CoderDecoder), and Jelly to be EF (EncapsulatorFragmentor). twisted.spread would then have to be renamed twisted.alphabetsoup, and then the whole food-pun thing would start all over again."><super>3</super></a>. Just remember

492

that perspectives and avatars are basically the same thing.

493

494

Despite all we've been <a href="cred.html" shape="rect">telling you</a> about how

495

Avatars are more of a concept than an actual class, the base class from

496

which you can create your server-side avatar-ish objects is, in fact, named

497

<code>pb.Avatar</code><a href="#footnote-4" title="The avatar-ish class is named pb.Avatar because pb.Perspective was already taken, by the (now obsolete) oldcred perspective-ish class. It is a pity, but it simply wasn't possible both replace pb.Perspective in-place and maintain a reasonable level of backwards-compatibility."><super>4</super></a>. These objects behave very much like

498

<code>pb.Referenceable</code>. The only difference is that instead of

499

offering <q>remote_FOO</q> methods, they offer <q>perspective_FOO</q>

500

methods.

501

502

The other way in which <code>pb.Avatar</code> differs from

503

<code>pb.Referenceable</code> is that the avatar objects are designed to be

504

the first thing retrieved by a cred-using remote client. Just as

505

<code>PBClientFactory.getRootObject</code> gives the client access to a

506

<code>pb.Root</code> object (which can then provide access to all kinds of

507

other objects), <code>PBClientFactory.login</code> gives client access to a

508

<code>pb.Avatar</code> object (which can return other references).

509

510

So, the first half of using cred in your PB application is to create an

511

Avatar object which implements <code>perspective_</code> methods and is

512

careful to do useful things for the remote user while remaining vigilant

513

against being tricked with unexpected argument values. It must also be

514

careful to never give access to objects that the user should not have access

515

to, whether by returning them directly, returning objects which contain

516

them, or returning objects which can be asked (remotely) to provide

517

them.

518

519

The second half is how the user gets a <code>pb.RemoteReference</code> to

520

your Avatar. As explained <a href="cred.html" shape="rect">elsewhere</a>, Avatars are

521

obtained from a Realm. The Realm doesn't deal with authentication at all

522

(usernames, passwords, public keys, challenge-response systems, retinal

523

scanners, real-time DNA sequencers, etc). It simply takes an <q>avatarID</q>

524

(which is effectively a username) and returns an Avatar object. The Portal

525

and its Checkers deal with authenticating the user: by the time they are

526

done, the remote user has proved their right to access the avatarID that is

527

given to the Realm, so the Realm can return a remotely-controllable object

528

that has whatever powers you wish to grant to this particular user.

529

530

For PB, the realm is expected to return a <code>pb.Avatar</code> (or

531

anything which implements <code>pb.IPerspective</code>, really, but there's

532

no reason to not return a <code>pb.Avatar</code> subclass). This object will

533

be given to the client just like a <code>pb.Root</code> would be without

534

cred, and the user can get access to other objects through it (if you let

535

them).

536

537

The basic idea is that there is a separate IPerspective-implementing

538

object (i.e. the Avatar subclass) (i.e. the <q>perspective</q>) for each

539

user, and only the authorized user gets a remote reference to that

540

object. You can store whatever permissions or capabilities the user

541

possesses in that object, and then use them when the user invokes a remote

542

method. You give the user access to the perspective object instead of the

543

objects that do the real work.

544

545

546

<h2>Perspective Examples<a name="auto7"/></h2>

547

548

Here is a brief example of using a pb.Avatar. Most of the support code

549

is magic for now: we'll explain it later.

550

551

<h3>One Client<a name="auto8"/></h3>

552

553

<div class="py-listing"><pre> 1

554

555

556

557

558

559

560

561

562

563

564

565

566

567

568

569

570

571

572

573

574

575

576

577

578

579

580

581

582

#!/usr/bin/env python

583

584

585

# See LICENSE for details.

586

587

from zope.interface import implements

588

589

from twisted.spread import pb

590

from twisted.cred import checkers, portal

591

from twisted.internet import reactor

592

593

class MyPerspective(pb.Avatar):

594

def __init__(self, name):

595

self.name = name

596

def perspective_foo(self, arg):

597

print "I am", self.name, "perspective_foo(",arg,") called on", self

598

599

class MyRealm:

600

implements(portal.IRealm)

601

def requestAvatar(self, avatarId, mind, *interfaces):

602

if pb.IPerspective not in interfaces:

603

raise NotImplementedError

604

return pb.IPerspective, MyPerspective(avatarId), lambda:None

605

606

p = portal.Portal(MyRealm())

607

p.registerChecker(

608

checkers.InMemoryUsernamePasswordDatabaseDontUse(user1="pass1"))

609

reactor.listenTCP(8800, pb.PBServerFactory(p))

610

reactor.run()

611

</pre><div class="caption">Source listing - <a href="listings/pb/pb5server.py">listings/pb/pb5server.py</a></div></div>

612

<div class="py-listing"><pre> 1

613

614

615

616

617

618

619

620

621

622

623

624

625

626

627

628

629

630

631

632

633

634

#!/usr/bin/env python

635

636

637

# See LICENSE for details.

638

639

640

641

642

643

def main():

644

factory = pb.PBClientFactory()

645

reactor.connectTCP("localhost", 8800, factory)

646

def1 = factory.login(credentials.UsernamePassword("user1", "pass1"))

647

def1.addCallback(connected)

648

reactor.run()

649

650

def connected(perspective):

651

print "got perspective ref:", perspective

652

print "asking it to foo(12)"

653

perspective.callRemote("foo", 12)

654

655

main()

656

</pre><div class="caption">Source listing - <a href="listings/pb/pb5client.py">listings/pb/pb5client.py</a></div></div>

657

658

Ok, so that wasn't really very exciting. It doesn't accomplish much more

659

than the first PB example, and used a lot more code to do it. Let's try it

660

again with two users this time.

661

662

<div class="note">Note:

663

664

When the client runs <code>login</code> to request the Perspective,

665

they can provide it with an optional <code>client</code> argument (which

666

must be a <code>pb.Referenceable</code> object). If they do, then a

667

reference to that object will be handed to the realm's

668

<code>requestAvatar</code> in the <code>mind</code> argument.

669

670

The server-side Perspective can use it to invoke remote methods on

671

something in the client, so that the client doesn't always have to drive the

672

interaction. In a chat server, the client object would be the one to which

673

<q>display text</q> messages were sent. In a board game server, this would

674

provide a way to tell the clients that someone has made a move, so they can

675

update their game boards.

676

677

</div>

678

679

<h3>Two Clients<a name="auto9"/></h3>

680

681

<div class="py-listing"><pre> 1

682

683

684

685

686

687

688

689

690

691

692

693

694

695

696

697

698

699

700

701

702

703

704

705

706

707

708

709

710

711

#!/usr/bin/env python

712

713

714

# See LICENSE for details.

715

716

717

718

719

720

721

722

class MyPerspective(pb.Avatar):

723

def __init__(self, name):

724

self.name = name

725

def perspective_foo(self, arg):

726

727

728

class MyRealm:

729

implements(portal.IRealm)

730

731

732

raise NotImplementedError

733

734

735

p = portal.Portal(MyRealm())

736

c = checkers.InMemoryUsernamePasswordDatabaseDontUse(user1="pass1",

737

user2="pass2")

738

p.registerChecker(c)

739

740

reactor.run()

741

</pre><div class="caption">Source listing - <a href="listings/pb/pb6server.py">listings/pb/pb6server.py</a></div></div>

742

<div class="py-listing"><pre> 1

743

744

745

746

747

748

749

750

751

752

753

754

755

756

757

758

759

760

761

762

763

764

#!/usr/bin/env python

765

766

767

# See LICENSE for details.

768

769

770

771

772

773

def main():

774

factory = pb.PBClientFactory()

775

776

777

def1.addCallback(connected)

778

reactor.run()

779

780

def connected(perspective):

781

print "got perspective1 ref:", perspective

782

print "asking it to foo(13)"

783

perspective.callRemote("foo", 13)

784

785

main()

786

</pre><div class="caption">Source listing - <a href="listings/pb/pb6client1.py">listings/pb/pb6client1.py</a></div></div>

787

<div class="py-listing"><pre> 1

788

789

790

791

792

793

794

795

796

797

798

799

800

801

802

803

804

805

806

807

808

809

810

811

812

#!/usr/bin/env python

813

814

815

# See LICENSE for details.

816

817

818

819

820

821

822

823

824

def main():

825

factory = pb.PBClientFactory()

826

827

def1 = factory.login(credentials.UsernamePassword("user2", "pass2"))

828

def1.addCallback(connected)

829

reactor.run()

830

831

def connected(perspective):

832

print "got perspective2 ref:", perspective

833

print "asking it to foo(14)"

834

perspective.callRemote("foo", 14)

835

836

main()

837

</pre><div class="caption">Source listing - <a href="listings/pb/pb6client2.py">listings/pb/pb6client2.py</a></div></div>

838

839

While pb6server.py is running, try starting pb6client1, then pb6client2.

840

Compare the argument passed by the <code>.callRemote()</code> in each

841

client. You can see how each client gets connected to a different

842

Perspective.

843

844

845

<h3>How that example worked<a name="auto10"/></h3><a name="smallexample" shape="rect"/>

846

847

Let's walk through the previous example and see what was going on.

848

849

First, we created a subclass called <code>MyPerspective</code> which is

850

our server-side Avatar. It implements a <code>perspective_foo</code> method

851

that is exposed to the remote client.

852

853

Second, we created a realm (an object which implements

854

<code>IRealm</code>, and therefore implements <code>requestAvatar</code>).

855

This realm manufactures <code>MyPerspective</code> objects. It makes as many

856

as we want, and names each one with the avatarID (a username) that comes out

857

of the checkers. This MyRealm object returns two other objects as well,

858

which we will describe later.

859

860

Third, we created a portal to hold this realm. The portal's job is to

861

dispatch incoming clients to the credential checkers, and then to request

862

Avatars for any which survive the authentication process.

863

864

Fourth, we made a simple checker (an object which implements

865

<code>IChecker</code>) to hold valid user/password pairs. The checker

866

gets registered with the portal, so it knows who to ask when new

867

clients connect. We use a checker named

868

<code>InMemoryUsernamePasswordDatabaseDontUse</code>, which suggests

869

that 1: all the username/password pairs are kept in memory instead of

870

being saved to a database or something, and 2: you shouldn't use

871

it. The admonition against using it is because there are better

872

schemes: keeping everything in memory will not work when you have

873

thousands or millions of users to keep track of, the passwords will be

874

stored in the .tap file when the application shuts down (possibly a

875

security risk), and finally it is a nuisance to add or remove users

876

after the checker is constructed.

877

878

Fifth, we create a <code>pb.PBServerFactory</code> to listen on a TCP

879

port. This factory knows how to connect the remote client to the Portal, so

880

incoming connections will be handed to the authentication process. Other

881

protocols (non-PB) would do something similar: the factory that creates

882

Protocol objects will give those objects access to the Portal so

883

authentication can take place.

884

885

On the client side, a <code>pb.PBClientFactory</code> is created (as <a href="pb-usage.html" shape="rect">before</a>) and attached to a TCP connection. When the

886

connection completes, the factory will be asked to produce a Protocol, and

887

it will create a PB object. Unlike the previous chapter, where we used

888

<code>.getRootObject</code>, here we use <code>factory.login</code> to

889

initiate the cred authentication process. We provide a

890

<code>credentials</code> object, which is the client-side agent for doing

891

our half of the authentication process. This process may involve several

892

messages: challenges, responses, encrypted passwords, secure hashes, etc. We

893

give our credentials object everything it will need to respond correctly (in

894

this case, a username and password, but you could write a credential that

895

used public-key encryption or even fancier techniques).

896

897

<code>login</code> returns a Deferred which, when it fires, will return a

898

<code>pb.RemoteReference</code> to the remote avatar. We can then do

899

<code>callRemote</code> to invoke a <code>perspective_foo</code> method on

900

that Avatar.

901

902

903

<h3>Anonymous Clients<a name="auto11"/></h3>

904

905

<div class="py-listing"><pre> 1

906

907

908

909

910

911

912

913

914

915

916

917

918

919

920

921

922

923

924

925

926

927

928

929

930

931

932

933

934

935

936

937

938

939

940

941

942

943

944

945

946

947

948

949

950

951

952

953

954

955

956

957

958

959

960

961

962

963

964

965

966

967

968

969

970

971

972

973

974

975

976

977

978

979

980

981

982

983

984

985

986

987

988

989

990

991

992

993

994

995

996

#!/usr/bin/env python

997

998

999

# See LICENSE for details.

1000

1001

"""

1002

Implement the realm for and run on port 8800 a PB service which allows both

1003

anonymous and username/password based access.

1004

1005

Successful username/password-based login requests given an instance of

1006

MyPerspective with a name which matches the username with which they

1007

authenticated. Success anonymous login requests are given an instance of

1008

MyPerspective with the name "Anonymous".

1009

"""

1010

1011

from sys import stdout

1012

1013

1014

1015

from twisted.python.log import startLogging

1016

from twisted.cred.checkers import ANONYMOUS, AllowAnonymousAccess

1017

1018

from twisted.cred.portal import IRealm, Portal

1019

1020

from twisted.spread.pb import Avatar, IPerspective, PBServerFactory

1021

1022

1023

class MyPerspective(Avatar):

1024

"""

1025

Trivial avatar exposing a single remote method for demonstrative

1026

purposes. All successful login attempts in this example will result in

1027

an avatar which is an instance of this class.

1028

1029

@type name: C{str}

1030

@ivar name: The username which was used during login or C{"Anonymous"}

1031

if the login was anonymous (a real service might want to avoid the

1032

collision this introduces between anonoymous users and authenticated

1033

users named "Anonymous").

1034

"""

1035

def __init__(self, name):

1036

self.name = name

1037

1038

1039

def perspective_foo(self, arg):

1040

"""

1041

Print a simple message which gives the argument this method was

1042

called with and this avatar's name.

1043

"""

1044

print "I am %s. perspective_foo(%s) called on %s." % (

1045

self.name, arg, self)

1046

1047

1048

1049

class MyRealm(object):

1050

"""

1051

Trivial realm which supports anonymous and named users by creating

1052

avatars which are instances of MyPerspective for either.

1053

"""

1054

implements(IRealm)

1055

1056

1057

if IPerspective not in interfaces:

1058

raise NotImplementedError("MyRealm only handles IPerspective")

1059

if avatarId is ANONYMOUS:

1060

avatarId = "Anonymous"

1061

return IPerspective, MyPerspective(avatarId), lambda: None

1062

1063

1064

1065

def main():

1066

"""

1067

Create a PB server using MyRealm and run it on port 8800.

1068

"""

1069

startLogging(stdout)

1070

1071

p = Portal(MyRealm())

1072

1073

# Here the username/password checker is registered.

1074

c1 = InMemoryUsernamePasswordDatabaseDontUse(user1="pass1", user2="pass2")

1075

p.registerChecker(c1)

1076

1077

# Here the anonymous checker is registered.

1078

c2 = AllowAnonymousAccess()

1079

p.registerChecker(c2)

1080

1081

reactor.listenTCP(8800, PBServerFactory(p))

1082

reactor.run()

1083

1084

1085

if __name__ == '__main__':

1086

main()

1087

</pre><div class="caption">Source listing - <a href="listings/pb/pbAnonServer.py">listings/pb/pbAnonServer.py</a></div></div>

1088

<div class="py-listing"><pre> 1

1089

1090

1091

1092

1093

1094

1095

1096

1097

1098

1099

1100

1101

1102

1103

1104

1105

1106

1107

1108

1109

1110

1111

1112

1113

1114

1115

1116

1117

1118

1119

1120

1121

1122

1123

1124

1125

1126

1127

1128

1129

1130

1131

1132

1133

1134

1135

1136

1137

1138

1139

1140

1141

1142

1143

1144

1145

1146

1147

1148

1149

1150

1151

1152

1153

1154

1155

1156

1157

1158

#!/usr/bin/env python

1159

1160

1161

# See LICENSE for details.

1162

1163

"""

1164

Client which will talk to the server run by pbAnonServer.py, logging in

1165

either anonymously or with username/password credentials.

1166

"""

1167

1168

from sys import stdout

1169

1170

1171

from twisted.cred.credentials import Anonymous, UsernamePassword

1172

1173

from twisted.internet.defer import gatherResults

1174

1175

1176

1177

def error(why, msg):

1178

"""

1179

Catch-all errback which simply logs the failure. This isn't expected to

1180

be invoked in the normal case for this example.

1181

"""

1182

err(why, msg)

1183

1184

1185

def connected(perspective):

1186

"""

1187

1188

which the server returned.

1189

"""

1190

print "got perspective1 ref:", perspective

1191

print "asking it to foo(13)"

1192

return perspective.callRemote("foo", 13)

1193

1194

1195

def finished(ignored):

1196

"""

1197

Callback invoked when both logins and method calls have finished to shut

1198

down the reactor so the example exits.

1199

"""

1200

reactor.stop()

1201

1202

1203

def main():

1204

"""

1205

Connect to a PB server running on port 8800 on localhost and log in to

1206

it, both anonymously and using a username/password it will recognize.

1207

"""

1208

startLogging(stdout)

1209

factory = PBClientFactory()

1210

1211

1212

anonymousLogin = factory.login(Anonymous())

1213

anonymousLogin.addCallback(connected)

1214

anonymousLogin.addErrback(error, "Anonymous login failed")

1215

1216

usernameLogin = factory.login(UsernamePassword("user1", "pass1"))

1217

usernameLogin.addCallback(connected)

1218

usernameLogin.addErrback(error, "Username/password login failed")

1219

1220

bothDeferreds = gatherResults([anonymousLogin, usernameLogin])

1221

bothDeferreds.addCallback(finished)

1222

1223

reactor.run()

1224

1225

1226

if __name__ == '__main__':

1227

main()

1228

</pre><div class="caption">Source listing - <a href="listings/pb/pbAnonClient.py">listings/pb/pbAnonClient.py</a></div></div>

1229

1230

pbAnonServer.py implements a server based on pb6server.py, extending it to

1231

permit anonymous logins in addition to authenticated logins. A

1232

<code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.cred.checkers.AllowAnonymousAccess.html" title="twisted.cred.checkers.AllowAnonymousAccess">AllowAnonymousAccess</a></code>

1233

checker and a <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.cred.checkers.

1234

.html" title="twisted.cred.checkers.

1235

1236

InMemoryUsernamePasswordDatabaseDontUse</a></code> checker are registered and the

1237

client's choice of credentials object determines which is used to authenticate

1238

the login. In either case, the realm will be called on to create an avatar for

1239

the login. <code>AllowAnonymousAccess</code> always produces an <code>avatarId

1240

</code> of <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.cred.checkers.ANONYMOUS.html" title="twisted.cred.checkers.ANONYMOUS">ANONYMOUS</a></code>.

1241

1242

On the client side, the only change is the use of an instance of

1243

<code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.cred.credentials.Anonymous.html" title="twisted.cred.credentials.Anonymous">Anonymous</a></code> when calling

1244

<code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.spread.pb.PBClientFactory.login.html" title="twisted.spread.pb.PBClientFactory.login">PBClientFactory.login</a></code>.

1245

1246

1247

<h2>Using Avatars<a name="auto12"/></h2>

1248

1249

1250

<h3>Avatar Interfaces<a name="auto13"/></h3>

1251

1252

The first element of the 3-tuple returned by <code>requestAvatar</code>

1253

indicates which Interface this Avatar implements. For PB avatars, it will

1254

always be <code>pb.IPerspective</code>, because that's the only interface

1255

these avatars implement.

1256

1257

This element is present because <code>requestAvatar</code> is actually

1258

presented with a list of possible Interfaces. The question being posed to

1259

the Realm is: <q>do you have an avatar for (avatarID) that can implement one

1260

of the following set of Interfaces?</q>. Some portals and checkers might

1261

give a list of Interfaces and the Realm could pick; the PB code only knows

1262

how to do one, so we cannot take advantage of this feature.

1263

1264

<h3>Logging Out<a name="auto14"/></h3>

1265

1266

The third element of the 3-tuple is a zero-argument callable, which will

1267

be invoked by the protocol when the connection has been lost. We can use

1268

this to notify the Avatar when the client has lost its connection. This will

1269

be described in more detail below.

1270

1271

<h3>Making Avatars<a name="auto15"/></h3>

1272

1273

In the example above, we create Avatars upon request, during

1274

<code>requestAvatar</code>. Depending upon the service, these Avatars might

1275

already exist before the connection is received, and might outlive the

1276

connection. The Avatars might also accept multiple connections.

1277

1278

Another possibility is that the Avatars might exist ahead of time, but in

1279

a different form (frozen in a pickle and/or saved in a database). In this

1280

case, <code>requestAvatar</code> may need to perform a database lookup and

1281

then do something with the result before it can provide an avatar. In this

1282

case, it would probably return a Deferred so it could provide the real

1283

Avatar later, once the lookup had completed.

1284

1285

Here are some possible implementations of

1286

<code>MyRealm.requestAvatar</code>:

1287

1288

<pre class="python"> 1

1289

1290

1291

1292

1293

1294

1295

1296

1297

1298

1299

1300

1301

1302

1303

1304

1305

1306

1307

1308

1309

1310

1311

1312

1313

1314

1315

1316

1317

1318

1319

1320

1321

1322

1323

1324

1325

# pre-existing, static avatars

1326

def requestAvatar(self, avatarID, mind, *interfaces):

1327

assert pb.IPerspective in interfaces

1328

avatar = self.avatars[avatarID]

1329

1330

1331

# database lookup and unpickling

1332

def requestAvatar(self, avatarID, mind, *interfaces):

1333

1334

d = self.database.fetchAvatar(avatarID)

1335

d.addCallback(self.doUnpickle)

1336

1337

def doUnpickle(self, pickled):

1338

avatar = pickle.loads(pickled)

1339

return avatar

1340

1341

# everybody shares the same Avatar

1342

def requestAvatar(self, avatarID, mind, *interfaces):

1343

1344

return pb.IPerspective, self.theOneAvatar, lambda:None

1345

1346

# anonymous users share one Avatar, named users each get their own

1347

def requestAvatar(self, avatarID, mind, *interfaces):

1348

1349

if avatarID == checkers.ANONYMOUS:

1350

return pb.IPerspective, self.anonAvatar, lambda:None

1351

else:

1352

return pb.IPerspective, self.avatars[avatarID], lambda:None

1353

1354

# anonymous users get independent (but temporary) Avatars

1355

# named users get their own persistent one

1356

def requestAvatar(self, avatarID, mind, *interfaces):

1357

1358

if avatarID == checkers.ANONYMOUS:

1359

1360

else:

1361

return pb.IPerspective, self.avatars[avatarID], lambda:None

1362

</pre>

1363

1364

The last example, note that the new <code>MyAvatar</code> instance is not

1365

saved anywhere: it will vanish when the connection is dropped. By contrast,

1366

the avatars that live in the <code>self.avatars</code> dictionary will

1367

probably get persisted into the .tap file along with the Realm, the Portal,

1368

and anything else that is referenced by the top-level Application object.

1369

This is an easy way to manage saved user profiles.

1370

1371

1372

<h3>Connecting and Disconnecting<a name="auto16"/></h3>

1373

1374

It may be useful for your Avatars to be told when remote clients gain

1375

(and lose) access to them. For example, and Avatar might be updated by

1376

something in the server, and if there are clients attached, it should update

1377

them (through the <q>mind</q> argument which lets the Avatar do callRemote

1378

on the client).

1379

1380

One common idiom which accomplishes this is to have the Realm tell the

1381

avatar that a remote client has just attached. The Realm can also ask the

1382

protocol to let it know when the connection goes away, so it can then inform

1383

the Avatar that the client has detached. The third member of the

1384

<code>requestAvatar</code> return tuple is a callable which will be invoked

1385

when the connection is lost.

1386

1387

<pre class="python"> 1

1388

1389

1390

1391

1392

1393

1394

1395

1396

1397

1398

1399

1400

1401

1402

1403

1404

1405

1406

class MyPerspective(pb.Avatar):

1407

def __init__(self):

1408

self.clients = []

1409

def attached(self, mind):

1410

self.clients.append(mind)

1411

print "attached to", mind

1412

def detached(self, mind):

1413

self.clients.remove(mind)

1414

print "detached from", mind

1415

def update(self, message):

1416

for c in self.clients:

1417

c.callRemote("update", message)

1418

1419

class MyRealm:

1420

def requestAvatar(self, avatarID, mind, *interfaces):

1421

1422

avatar = self.avatars[avatarID]

1423

avatar.attached(mind)

1424

return pb.IPerspective, avatar, lambda a=avatar:a.detached(mind)

1425

</pre>

1426

1427

1428

<h3>Viewable<a name="auto17"/></h3> <a name="viewable" shape="rect"/>

1429

1430

Once you have <code>IPerspective</code> objects (i.e. the Avatar) to

1431

represent users, the <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.spread.flavors.Viewable.html" title="twisted.spread.flavors.Viewable">Viewable</a></code> class can come into play. This

1432

class behaves a lot like <code>Referenceable</code>: it turns into a

1433

<code>RemoteReference</code> when sent over the wire, and certain methods

1434

can be invoked by the holder of that reference. However, the methods that

1435

can be called have names that start with <code>view_</code> instead of

1436

<code>remote_</code>, and those methods are always called with an extra

1437

<code>perspective</code> argument that points to the Avatar through which

1438

the reference was sent:

1439

1440

<pre class="python">1

1441

1442

1443

class Foo(pb.Viewable):

1444

def view_doFoo(self, perspective, arg1, arg2):

1445

pass

1446

</pre>

1447

1448

This is useful if you want to let multiple clients share a reference to

1449

the same object. The <code>view_</code> methods can use the

1450

<q>perspective</q> argument to figure out which client is calling them. This

1451

gives them a way to do additional permission checks, do per-user accounting,

1452

etc.

1453

1454

This is the shortcut which makes per-user-per-group capability objects

1455

much easier to use. Instead of creating such per-(user,group) objects, you

1456

just have per-group objects which inherit from <code>pb.Viewable</code>, and

1457

give the user references to them. The local <code>pb.Avatar</code> object

1458

will automatically show up as the <q>perspective</q> argument in the

1459

<code>view_*</code> method calls, give you a chance to involve the Avatar in

1460

the process.

1461

1462

1463

<h3>Chat Server with Avatars<a name="auto18"/></h3>

1464

1465

Combining all the above techniques, here is an example chat server which

1466

uses a fixed set of identities (say, for the three members of your bridge

1467

club, who hang out in <q>#NeedAFourth</q> hoping that someone will discover

1468

your server, guess somebody's password, break in, join the group, and also

1469

be available for a game next saturday afternoon).

1470

1471

<div class="py-listing"><pre> 1

1472

1473

1474

1475

1476

1477

1478

1479

1480

1481

1482

1483

1484

1485

1486

1487

1488

1489

1490

1491

1492

1493

1494

1495

1496

1497

1498

1499

1500

1501

1502

1503

1504

1505

1506

1507

1508

1509

1510

1511

1512

1513

1514

1515

1516

1517

1518

1519

1520

1521

1522

1523

1524

1525

1526

1527

1528

1529

1530

1531

1532

1533

1534

1535

1536

#!/usr/bin/env python

1537

1538

1539

# See LICENSE for details.

1540

1541

1542

1543

from twisted.cred import portal, checkers

1544

1545

1546

1547

class ChatServer:

1548

def __init__(self):

1549

self.groups = {} # indexed by name

1550

1551

1552

1553

1554

self.groups[groupname].addUser(user)

1555

return self.groups[groupname]

1556

1557

class ChatRealm:

1558

implements(portal.IRealm)

1559

def requestAvatar(self, avatarID, mind, *interfaces):

1560

1561

avatar = User(avatarID)

1562

avatar.server = self.server

1563

avatar.attached(mind)

1564

return pb.IPerspective, avatar, lambda a=avatar:a.detached(mind)

1565

1566

class User(pb.Avatar):

1567

def __init__(self, name):

1568

self.name = name

1569

def attached(self, mind):

1570

self.remote = mind

1571

def detached(self, mind):

1572

self.remote = None

1573

def perspective_joinGroup(self, groupname, allowMattress=True):

1574

1575

def send(self, message):

1576

1577

1578

class Group(pb.Viewable):

1579

def __init__(self, groupname, allowMattress):

1580

self.name = groupname

1581

self.allowMattress = allowMattress

1582

self.users = []

1583

def addUser(self, user):

1584

self.users.append(user)

1585

def view_send(self, from_user, message):

1586

1587

raise ValueError, "Don't say that word"

1588

1589

user.send("<%s> says: %s" % (from_user.name, message))

1590

1591

realm = ChatRealm()

1592

realm.server = ChatServer()

1593

checker = checkers.InMemoryUsernamePasswordDatabaseDontUse()

1594

checker.addUser("alice", "1234")

1595

checker.addUser("bob", "secret")

1596

checker.addUser("carol", "fido")

1597

p = portal.Portal(realm, [checker])

1598

1599

1600

reactor.run()

1601

</pre><div class="caption">Source listing - <a href="listings/pb/chatserver.py">listings/pb/chatserver.py</a></div></div>

1602

1603

Notice that the client uses <code>perspective_joinGroup</code> to both

1604

join a group and retrieve a <code>RemoteReference</code> to the

1605

<code>Group</code> object. However, the reference they get is actually to a

1606

special intermediate object called a <code>pb.ViewPoint</code>. When they do

1607

<code>group.callRemote("send", "message")</code>, their avatar is inserted

1608

into the argument list that <code>Group.view_send</code> actually sees. This

1609

lets the group get their username out of the Avatar without giving the

1610

client an opportunity to spoof someone else.

1611

1612

The client side code that joins a group and sends a message would look

1613

like this:

1614

1615

<div class="py-listing"><pre> 1

1616

1617

1618

1619

1620

1621

1622

1623

1624

1625

1626

1627

1628

1629

1630

1631

1632

1633

1634

1635

1636

1637

1638

1639

1640

1641

1642

1643

1644

1645

1646

1647

1648

1649

1650

1651

1652

1653

1654

1655

#!/usr/bin/env python

1656

1657

1658

# See LICENSE for details.

1659

1660

1661

1662

1663

1664

class Client(pb.Referenceable):

1665

1666

def remote_print(self, message):

1667

print message

1668

1669

def connect(self):

1670

factory = pb.PBClientFactory()

1671

1672

def1 = factory.login(credentials.UsernamePassword("alice", "1234"),

1673

client=self)

1674

def1.addCallback(self.connected)

1675

reactor.run()

1676

1677

def connected(self, perspective):

1678

print "connected, joining group #lookingForFourth"

1679

# this perspective is a reference to our User object

1680

d = perspective.callRemote("joinGroup", "#lookingForFourth")

1681

d.addCallback(self.gotGroup)

1682

1683

def gotGroup(self, group):

1684

print "joined group, now sending a message to all members"

1685

# 'group' is a reference to the Group object (through a ViewPoint)

1686

d = group.callRemote("send", "You can call me Al.")

1687

d.addCallback(self.shutdown)

1688

1689

def shutdown(self, result):

1690

reactor.stop()

1691

1692

1693

Client().connect()

1694

</pre><div class="caption">Source listing - <a href="listings/pb/chatclient.py">listings/pb/chatclient.py</a></div></div>

1695

1696

1697

<h2>Footnotes</h2><ol><li><a name="footnote-1">Apparently Alice is one of those weirdos who has nothing

1698

better to do than to try and impersonate Bob. She will lie to her chat

1699

client, send incorrect objects to remote methods, even rewrite her local

1700

client code entirely to accomplish this juvenile prank. Given this

1701

adversarial relationship, one must wonder why she and Bob seem to spend so

1702

much time together: their adventures are clearly documented by the

1703

cryptographic literature.</a></li><li><a name="footnote-2">the

1704

obvious name is clearly

1705

<code>ServerSidePerUserObjectWhichNobodyElseHasAccessTo</code>, but because

1706

python makes everything else so easy to read, it only seems fair to make

1707

your audience work for something</a></li><li><a name="footnote-3">We could just go ahead and rename Perspective Broker to be

1708

Avatar Broker, but 1) that would cause massive compatibility problems, and 2)

1709

<q>AB</q> doesn't fit into the whole sandwich-themed naming scheme nearly as

1710

well as <q>PB</q> does. If we changed it to AB, we'd probably have to change

1711

Banana to be CD (CoderDecoder), and Jelly to be EF (EncapsulatorFragmentor).

1712

twisted.spread would then have to be renamed twisted.alphabetsoup, and then

1713

the whole food-pun thing would start all over again.</a></li><li><a name="footnote-4">The avatar-ish class is named

1714

<code>pb.Avatar</code> because <code>pb.Perspective</code> was already

1715

taken, by the (now obsolete) oldcred perspective-ish class. It is a pity,

1716

but it simply wasn't possible both replace <code>pb.Perspective</code>

1717

in-place and maintain a reasonable level of

1718

backwards-compatibility.</a></li></ol></div>

1719

1720

<a href="index.html">Index</a>

1721

Version: 10.0.0

1722

</body>

1723

</html>

b'\\ No newline at end of file'

Older »