You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It was a dirty hack that worked for a while, but, it had several fatal flaws.
93
-
1. Once we added Message Management support we needed to duplicate this code to rename the 'SESSION' key to 'MM_SESSION', which is less than ideal due to code duplication
94
-
2. This allowed you to only have one active session, even in shared memory space (ie threads)
95
-
3. Due to the not-so-global scope of globals, this session was really only "global" in the scope of the dyn.tm module. It could still be accessed externally, but it just made me feel dirty knowing that that was what was happening.
84
+
While this worked for a short while, it had its flaws:
85
+
1. Once Message Management support was added, the code needed to be duplicated to rename the ‘SESSION’ key to ‘MM_SESSION’. This was inefficient.
86
+
2. This allowed you to only have one active Session, even in shared memory space, i.e. threads.
87
+
3. Sessions were only truly “global” in the scope of the dyn.tm module. It could still be accessed externally, but it was less than ideal.
96
88
97
89
What We Do Now
98
90
^^^^^^^^^^^^^^
99
-
So, as of v1.0.0 this is not how the Session types are implemented anymore. Yes, they
100
-
are still Singletons, however, they're implemented completely differently.
91
+
As of v1.0.0, Session types remain Singletons but are implemented differently.
101
92
102
-
Now, on top of these Sessions being implemented as :class:`dyn.core.SessionEngine`
103
-
objects, they are also :class:`dyn.core.Singleton` *type* objects. What do these
104
-
look like you ask?::
93
+
Sessions are now implemented as :class:`dyn.core.SessionEngine` objects
94
+
and :class:`dyn.core.Singleton` *type* objects. EXAMPLE::
105
95
106
96
class Singleton(type):
107
97
"""A :class:`Singleton` type for implementing a true Singleton design
@@ -119,44 +109,40 @@ look like you ask?::
119
109
}
120
110
return cls._instances[key][cur_thread]
121
111
122
-
So, the Singleton type is applied as a *__metaclass__* in each of the two Session
123
-
types. This allows for a much cleaner implementation of Singletons where every time
124
-
one is accessed it will globally (actually globally this time) have knowledge of
125
-
other instances, since those instances are tied to the classes themselves instead
126
-
of held in the *globals* of the session modules. In addition this allows users
127
-
to have multiple active sessions across multiple threads, which was previously
128
-
impossible in the prior implementation.
112
+
The Singleton type is applied as a *__metaclass__* in each of the two Session
113
+
types. This allows for a much cleaner implementation of Singletons. Every time
114
+
one is accessed, it will globally have knowledge of other instances, as those
115
+
instancesare tied to the classes themselves instead of held in the *globals*
116
+
of the session modules. In addition, this allows users to have multiple active
117
+
sessions across multiple threads, which was not possible in the prior
118
+
implementation.
129
119
130
120
131
121
Password Encryption
132
122
-------------------
133
-
The DynECT REST API only accepts passwords in plain text, and currently there is
134
-
no way around that. However, for those of you that are particularly mindful of
135
-
security (and even those of you who aren't) can probably see some serious pitfalls
136
-
to this. As far as most users of this library are concerned the passwords stored in
137
-
their :class:`~dyn.tm.session.DynectSession` objects will only ever live in memory,
138
-
so it's really not a huge deal that their passwords are stored in plain text. However,
139
-
for users looking to do more advanced things, such as serialize and store their session
140
-
objects in something less secure, such as a database, then these plain text passwords
141
-
are far less than ideal. Because of this in version 1.1.0 we've added optional
142
-
AES-256 password encryption for all :class:`~dyn.tm.session.DynectSession`
143
-
instances. All you need to do to enable password encryption is install
144
-
`PyCrypto <http://www.dlitz.net/software/pycrypto/>`_. The rest will happen
145
-
automatically.
123
+
The Managed DNS REST API only accepts passwords in plain text. The
124
+
passwords stored in :class:`~dyn.tm.session.DynectSession` objects only
125
+
live in memory, reducing the security risk of plain text passwords in this instance.
126
+
However, for users looking to do more advanced things, such as serialize and store
127
+
their session objects in something less secure, such as a database, these
128
+
plain text passwords are not ideal. In response to this, Dyn added optional AES-256
129
+
password encryption for all :class:`~dyn.tm.session.DynectSession` instances in
130
+
version 1.1.0. To enable password encryption, install
0 commit comments