[DONE] wml://security/2014/dla-{37,65}.wml
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
- --- english/security/2014/dla-37.wml 2016-04-09 01:32:21.000000000 +0500
+++ russian/security/2014/dla-37.wml 2016-06-28 14:01:57.061323842 +0500
@@ -1,51 +1,52 @@
- -<define-tag description>LTS security update</define-tag>
+#use wml::debian::translation-check translation="1.3" maintainer="Lev Lamberov"
+<define-tag description>обновление безопаÑ?ноÑ?Ñ?и LTS</define-tag>
<define-tag moreinfo>
- -<p>Several vulnerabilities were discovered in krb5, the MIT implementation
- -of Kerberos. The Common Vulnerabilities and Exposures project identifies
- -the following problems:</p>
+<p>Ð? krb5, Ñ?еалиазаÑ?ии Kerberos оÑ? MIT, бÑ?ло обнаÑ?Ñ?жено неÑ?колÑ?ко
+Ñ?Ñ?звимоÑ?Ñ?ей. Ð?Ñ?оекÑ? Common Vulnerabilities and Exposures опÑ?еделÑ?еÑ?
+Ñ?ледÑ?Ñ?Ñ?ие пÑ?облемÑ?:</p>
<ul>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2014-4341";>CVE-2014-4341</a>
- - <p>An unauthenticated remote attacker with the ability to inject
- - packets into a legitimately established GSSAPI application session
- - can cause a program crash due to invalid memory references when
- - attempting to read beyond the end of a buffer.</p></li>
+ <p>Ð?еаÑ?Ñ?енÑ?иÑ?иÑ?иÑ?ованнÑ?й Ñ?далÑ?ннÑ?й злоÑ?мÑ?Ñ?ленник, Ñ?поÑ?обнÑ?й вÑ?полнÑ?Ñ?Ñ? инÑ?екÑ?иÑ?
+ пакеÑ?ов в коÑ?Ñ?екÑ?но Ñ?Ñ?Ñ?ановленнÑ?Ñ? Ñ?еÑ?Ñ?иÑ? GSSAPI-пÑ?иложениÑ?,
+ можеÑ? вÑ?зÑ?ваÑ?Ñ? аваÑ?ийнÑ?Ñ? оÑ?Ñ?ановкÑ? пÑ?огÑ?аммÑ? из-за непÑ?авилÑ?нÑ?Ñ? Ñ?казаний облаÑ?Ñ?ей памÑ?Ñ?и пÑ?и
+ попÑ?Ñ?ке Ñ?Ñ?ениÑ? за пÑ?еделами вÑ?деленного бÑ?Ñ?еÑ?а.</p></li>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2014-4342";>CVE-2014-4342</a>
- - <p>An unauthenticated remote attacker with the ability to inject
- - packets into a legitimately established GSSAPI application session
- - can cause a program crash due to invalid memory references when
- - reading beyond the end of a buffer or by causing a null pointer
- - dereference.</p></li>
+ <p>Ð?еаÑ?Ñ?енÑ?иÑ?иÑ?иÑ?ованнÑ?й Ñ?далÑ?ннÑ?й злоÑ?мÑ?Ñ?ленник, Ñ?поÑ?обнÑ?й вÑ?полнÑ?Ñ?Ñ? инÑ?екÑ?иÑ?
+ пакеÑ?ов в коÑ?Ñ?екÑ?но Ñ?Ñ?Ñ?ановленнÑ?Ñ? Ñ?еÑ?Ñ?иÑ? GSSAPI-пÑ?иложениÑ?,
+ можеÑ? вÑ?зÑ?ваÑ?Ñ? аваÑ?ийнÑ?Ñ? оÑ?Ñ?ановкÑ? пÑ?огÑ?аммÑ? из-за непÑ?авилÑ?нÑ?Ñ? Ñ?казаний облаÑ?Ñ?ей памÑ?Ñ?и пÑ?и
+ Ñ?Ñ?ении за пÑ?еделами вÑ?деленного бÑ?Ñ?еÑ?а или из-за Ñ?азÑ?менованиÑ?
+ null-Ñ?казаÑ?елÑ?.</p></li>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2014-4343";>CVE-2014-4343</a>
- - <p>An unauthenticated remote attacker with the ability to spoof packets
- - appearing to be from a GSSAPI acceptor can cause a double-free
- - condition in GSSAPI initiators (clients) which are using the SPNEGO
- - mechanism, by returning a different underlying mechanism than was
- - proposed by the initiator. A remote attacker could exploit this flaw
- - to cause an application crash or potentially execute arbitrary code.</p></li>
+ <p>Ð?еаÑ?Ñ?енÑ?иÑ?иÑ?иÑ?ованнÑ?й Ñ?далÑ?ннÑ?й злоÑ?мÑ?Ñ?ленник, Ñ?поÑ?обнÑ?й подделÑ?ваÑ?Ñ? пакеÑ?Ñ? Ñ?ак, Ñ?Ñ?о
+ они кажÑ?Ñ?Ñ?Ñ? иÑ?Ñ?одÑ?Ñ?ими оÑ? пÑ?инимаÑ?Ñ?ей Ñ?Ñ?оÑ?онÑ? GSSAPI, можеÑ? вÑ?зÑ?ваÑ?Ñ? Ñ?оÑ?Ñ?оÑ?ние двойного
+ оÑ?вобождениÑ? памÑ?Ñ?и в иниÑ?иаÑ?оÑ?аÑ? GSSAPI (клиенÑ?аÑ?), иÑ?полÑ?зÑ?Ñ?Ñ?иÑ? меÑ?анизм
+ SPNEGO, возвÑ?аÑ?аÑ? базовÑ?й меÑ?анизм, оÑ?лиÑ?нÑ?й оÑ?
+ пÑ?едложенного иниÑ?иаÑ?оÑ?ом. УдалÑ?ннÑ?й злоÑ?мÑ?Ñ?ленник можеÑ? иÑ?полÑ?зоваÑ?Ñ? Ñ?Ñ?Ñ? Ñ?Ñ?звимоÑ?Ñ?Ñ?
+ длÑ? вÑ?зова аваÑ?ийной оÑ?Ñ?ановки пÑ?иложениÑ? или поÑ?енÑ?иалÑ?ного вÑ?полнениÑ? пÑ?оизволÑ?ного кода.</p></li>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2014-4344";>CVE-2014-4344</a>
- - <p>An unauthenticated or partially authenticated remote attacker can
- - cause a NULL dereference and application crash during a SPNEGO
- - negotiation by sending an empty token as the second or later context
- - token from initiator to acceptor.</p></li>
+ <p>Ð?еаÑ?Ñ?енÑ?иÑ?иÑ?иÑ?ованнÑ?й или Ñ?аÑ?Ñ?иÑ?но аÑ?Ñ?енÑ?иÑ?иÑ?иÑ?ованнÑ?й Ñ?далÑ?ннÑ?й злоÑ?мÑ?Ñ?ленник можеÑ?
+ вÑ?зÑ?ваÑ?Ñ? Ñ?азÑ?менование NULL-Ñ?казаÑ?елÑ? и аваÑ?ийнÑ?Ñ? оÑ?Ñ?ановкÑ? пÑ?иложениÑ? в Ñ?оде Ñ?оглаÑ?ованиÑ?
+ SPNEGO пÑ?Ñ?Ñ?м оÑ?пÑ?авки пÑ?Ñ?Ñ?ого Ñ?окена в каÑ?еÑ?Ñ?ве вÑ?оÑ?ого или поÑ?ледÑ?Ñ?Ñ?его конÑ?екÑ?Ñ?ного
+ Ñ?окена оÑ? иниÑ?иаÑ?оÑ?а пÑ?инимаÑ?Ñ?ей Ñ?Ñ?оÑ?оне.</p></li>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2014-4345";>CVE-2014-4345</a>
- - <p>When kadmind is configured to use LDAP for the KDC database, an
- - authenticated remote attacker can cause it to perform an
- - out-of-bounds write (buffer overflow).</p></li>
+ <p>Ð?Ñ?ли kadmind наÑ?Ñ?Ñ?оен на иÑ?полÑ?зование LDAP длÑ? базÑ? даннÑ?Ñ? KDC, Ñ?о
+ аÑ?Ñ?енÑ?иÑ?иÑ?иÑ?ованнÑ?й Ñ?далÑ?ннÑ?й злоÑ?мÑ?Ñ?ленник можеÑ? вÑ?зÑ?ваÑ?Ñ? запиÑ?Ñ? за
+ пÑ?еделами вÑ?деленного бÑ?Ñ?еÑ?а (пеÑ?еполнение бÑ?Ñ?еÑ?а).</p></li>
</ul>
- -<p>For Debian 6 <q>Squeeze</q>, these issues have been fixed in krb5 version 1.8.3+dfsg-4squeeze8</p>
+<p>Ð? Debian 6 <q>Squeeze</q> Ñ?Ñ?и пÑ?облемÑ? бÑ?ли иÑ?пÑ?авленÑ? в пакеÑ?е krb5 веÑ?Ñ?ии 1.8.3+dfsg-4squeeze8</p>
</define-tag>
# do not modify the following line
- --- english/security/2014/dla-65.wml 2016-04-09 01:32:21.000000000 +0500
+++ russian/security/2014/dla-65.wml 2016-06-28 15:36:08.493784791 +0500
@@ -1,90 +1,91 @@
- -<define-tag description>LTS security update</define-tag>
+#use wml::debian::translation-check translation="1.3" maintainer="Lev Lamberov"
+<define-tag description>обновление безопаÑ?ноÑ?Ñ?и LTS</define-tag>
<define-tag moreinfo>
- -<p>This update address an issue with reverse() generating external URLs; a
- -denial of service involving file uploads; a potential session hijacking
- -issue in the remote-user middleware; and a data leak in the administrative
- -interface.</p>
+<p>Ð?анное обновление иÑ?пÑ?авлÑ?еÑ? пÑ?облемÑ? Ñ? Ñ?Ñ?нкÑ?ией reverse(), поÑ?ождаÑ?Ñ?ей внеÑ?ние URL;
+оÑ?каз в обÑ?лÑ?живании, каÑ?аÑ?Ñ?ийÑ?Ñ? загÑ?Ñ?зок Ñ?айлов; поÑ?енÑ?иалÑ?ное Ñ?иÑ?ение Ñ?еÑ?Ñ?ии
+Ñ? помоÑ?Ñ?Ñ? Ñ?далÑ?нного Ð?Ð? пÑ?омежÑ?Ñ?оÑ?ного Ñ?Ñ?овнÑ?; Ñ?Ñ?еÑ?кÑ? даннÑ?Ñ? в инÑ?еÑ?Ñ?ейÑ?е
+админиÑ?Ñ?Ñ?аÑ?оÑ?а.</p>
- -<p>This update has been brought to you thanks to the Debian LTS sponsors:
+<p>Ð?анное обновление Ñ?оздано благодаÑ?Ñ? Ñ?понÑ?оÑ?ам Debian LTS:
<a href="http://www.freexian.com/services/debian-lts.html";>http://www.freexian.com/services/debian-lts.html</a></p>
<ul>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2014-0480";>CVE-2014-0480</a>
- - <p>Django includes the helper function django.core.urlresolvers.reverse,
- - typically used to generate a URL from a reference to a view function or
- - URL pattern name. However, when presented with input beginning with two
- - forward-slash characters (//), reverse() could generate scheme-relative
- - URLs to other hosts, allowing an attacker who is aware of unsafe use of
- - reverse() (i.e., in a situation where an end user can control the target
- - of a redirect, to take a common example) to generate links to sites of
- - their choice, enabling phishing and other attacks.</p>
- -
- - <p>To remedy this, URL reversing now ensures that no URL starts with two
- - slashes (//), replacing the second slash with its URL encoded counterpart
- - (%2F). This approach ensures that semantics stay the same, while making
- - the URL relative to the domain and not to the scheme.</p></li>
+ <p>Django вклÑ?Ñ?аеÑ? в Ñ?ебÑ? вÑ?помогаÑ?елÑ?нÑ?Ñ? Ñ?Ñ?нкÑ?иÑ? django.core.urlresolvers.reverse,
+ обÑ?Ñ?но иÑ?полÑ?зÑ?емÑ?Ñ? длÑ? Ñ?озданиÑ? URL из Ñ?Ñ?Ñ?лки на Ñ?Ñ?нкÑ?иÑ? вида или
+ имÑ? Ñ?аблона URL. Тем не менее, еÑ?ли еÑ? пеÑ?еданÑ? вÑ?однÑ?е даннÑ?е, наÑ?инаÑ?Ñ?иеÑ?Ñ? Ñ? двÑ?Ñ?
+ коÑ?Ñ?Ñ? Ñ?еÑ?Ñ? (//), Ñ?о reverse() Ñ?оздаÑ?Ñ? оÑ?ноÑ?иÑ?елÑ?нÑ?е (оÑ?ноÑ?иÑ?елÑ?но Ñ?Ñ?емÑ?) URL
+ к дÑ?Ñ?гим Ñ?злам, Ñ?Ñ?о позволÑ?еÑ? злоÑ?мÑ?Ñ?ленникÑ?, коÑ?оÑ?омÑ? извеÑ?Ñ?но о небезопаÑ?ном иÑ?полÑ?зовании
+ Ñ?Ñ?нкÑ?ии reverse() (напÑ?имеÑ?, в Ñ?иÑ?Ñ?аÑ?ии, когда конеÑ?нÑ?й полÑ?зоваÑ?елÑ? можеÑ? Ñ?пÑ?авлÑ?Ñ?Ñ? Ñ?елÑ?Ñ?
+ пеÑ?енапÑ?авлениÑ?), Ñ?оздаваÑ?Ñ? Ñ?Ñ?Ñ?лки на Ñ?айÑ?Ñ? по его
+ вÑ?боÑ?Ñ?, Ñ?Ñ?о позволÑ?еÑ? вÑ?полнÑ?Ñ?Ñ? вÑ?Ñ?живание и дÑ?Ñ?гие видÑ? аÑ?ак.</p>
+
+ <p>Ð?лÑ? иÑ?пÑ?авлениÑ? Ñ?Ñ?ой пÑ?облемÑ? пÑ?и пÑ?еобÑ?азовании URL Ñ?епеÑ?Ñ? вÑ?полнÑ?еÑ? пÑ?овеÑ?ка Ñ?ого, Ñ?Ñ?о URL не наÑ?инаеÑ?Ñ?Ñ? Ñ?
+ двÑ?Ñ? коÑ?Ñ?Ñ? Ñ?еÑ?Ñ? (//), а Ñ?акже замена вÑ?оÑ?ой коÑ?ой Ñ?еÑ?Ñ?Ñ? на закодиÑ?ованнÑ?й Ñ?квиваленÑ?
+ (%2F). Такой подÑ?од гаÑ?анÑ?иÑ?Ñ?еÑ?, Ñ?Ñ?о Ñ?еманÑ?ика оÑ?Ñ?аÑ?Ñ?Ñ?Ñ? Ñ?ой же, а Ñ?оздаÑ?Ñ?Ñ?Ñ?
+ URL оÑ?ноÑ?иÑ?елÑ?но домена, а не оÑ?ноÑ?иÑ?елÑ?но Ñ?Ñ?емÑ?.</p></li>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2014-0481";>CVE-2014-0481</a>
- - <p>In the default configuration, when Django's file upload handling system is
- - presented with a file that would have the same on-disk path and name as an
- - existing file, it attempts to generate a new unique filename by appending
- - an underscore and an integer to the end of the (as stored on disk)
- - filename, incrementing the integer (i.e., _1, _2, etc.) until it has
- - generated a name which does not conflict with any existing file.</p>
- -
- - <p>An attacker with knowledge of this can exploit the sequential behavior of
- - filename generation by uploading many tiny files which all share a
- - filename; Django will, in processing them, generate ever-increasing
- - numbers of os.stat() calls as it attempts to generate a unique filename.
- - As a result, even a relatively small number of such uploads can
- - significantly degrade performance.</p>
- -
- - <p>To remedy this, Django's file-upload system will no longer use sequential
- - integer names to avoid filename conflicts on disk; instead, a short random
- - alphanumeric string will be appended, removing the ability to reliably
- - generate many repeatedly-conflicting filenames.</p></li>
+ <p>Ð?Ñ?и наÑ?Ñ?Ñ?ойкаÑ? по Ñ?молÑ?аниÑ? когда Ñ?иÑ?Ñ?ема Django длÑ? обÑ?абоÑ?ки загÑ?Ñ?зки Ñ?айлов
+ полÑ?Ñ?аеÑ? Ñ?айл, коÑ?оÑ?Ñ?й должен имеÑ?Ñ? пÑ?Ñ?Ñ? и имÑ?, Ñ?овпадаÑ?Ñ?ие Ñ? Ñ?же Ñ?Ñ?Ñ?еÑ?Ñ?вÑ?Ñ?Ñ?им
+ Ñ?айлом, Ñ?о делаеÑ?Ñ?Ñ? попÑ?Ñ?ка Ñ?оздаÑ?Ñ? новое Ñ?никалÑ?ное имÑ? Ñ?айла пÑ?Ñ?Ñ?м добавлениÑ?
+ Ñ?имвола подÑ?Ñ?Ñ?киваниÑ? и Ñ?елого Ñ?иÑ?ле в конÑ?е (Ñ?оÑ?Ñ?анÑ?емого на диÑ?к)
+ имени Ñ?айла, пÑ?и Ñ?Ñ?ом Ñ?иÑ?ло Ñ?велиÑ?иваеÑ?Ñ?Ñ? (напÑ?имеÑ?, _1, _2 и Ñ?. д.) до Ñ?еÑ? поÑ?, пока
+ не бÑ?деÑ? Ñ?оздано Ñ?акое имÑ? Ñ?айла, коÑ?оÑ?ое не вÑ?Ñ?Ñ?паеÑ? в конÑ?ликÑ? Ñ? Ñ?же Ñ?Ñ?Ñ?еÑ?Ñ?вÑ?Ñ?Ñ?ими Ñ?айлами.</p>
+
+ <p>Ð?лоÑ?мÑ?Ñ?ленник можеÑ? иÑ?полÑ?зоваÑ?Ñ? поÑ?ледоваÑ?елÑ?ное поведение кода длÑ?
+ Ñ?озданиÑ? имени Ñ?айла, загÑ?Ñ?зив множеÑ?Ñ?во неболÑ?Ñ?иÑ? Ñ?айлов, имеÑ?Ñ?иÑ? одно и Ñ?о же
+ имÑ?; в Ñ?оде иÑ? обÑ?абоÑ?ки Django поÑ?ождаеÑ? Ñ?велиÑ?иваÑ?Ñ?ееÑ?Ñ? Ñ?иÑ?ло
+ вÑ?зовов os.stat() в попÑ?Ñ?ке Ñ?озданиÑ? Ñ?никалÑ?ного имени Ñ?айла.
+ Ð? Ñ?езÑ?лÑ?Ñ?аÑ?е даже оÑ?ноÑ?иÑ?елÑ?но неболÑ?Ñ?ое Ñ?иÑ?ло Ñ?акиÑ? загÑ?Ñ?зок можеÑ?
+ Ñ?Ñ?Ñ?еÑ?Ñ?венно Ñ?низиÑ?Ñ? пÑ?оизводиÑ?елÑ?ноÑ?Ñ?Ñ? Ñ?иÑ?Ñ?емÑ?.</p>
+
+ <p>Ð?лÑ? иÑ?пÑ?авлениÑ? Ñ?Ñ?ой пÑ?облемÑ? Ñ?иÑ?Ñ?ема загÑ?Ñ?зки Ñ?айлов в Django более не иÑ?полÑ?зÑ?еÑ? поÑ?ледоваÑ?елÑ?нÑ?е
+ имена Ñ? Ñ?елÑ?ми Ñ?иÑ?лами длÑ? Ñ?ого, Ñ?Ñ?обÑ? не пÑ?оиÑ?Ñ?одили конÑ?ликÑ?Ñ? на диÑ?ке; вмеÑ?Ñ?о Ñ?Ñ?ого к имени Ñ?айла
+ добавлÑ?еÑ?Ñ?Ñ? коÑ?оÑ?каÑ? Ñ?лÑ?Ñ?айнаÑ? Ñ?Ñ?Ñ?ока Ñ? Ñ?иÑ?лами и бÑ?квами, Ñ?Ñ?о не позволÑ?еÑ? иÑ?полÑ?зоваÑ?Ñ?
+ Ñ?оздание множеÑ?Ñ?ва конÑ?ликÑ?Ñ?Ñ?Ñ?иÑ? имÑ?н Ñ?айлов.</p></li>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2014-0482";>CVE-2014-0482</a>
- - <p>Django provides a middleware django.contrib.auth.middleware.RemoteUserMiddleware -- and an
- - authentication backend, django.contrib.auth.backends.RemoteUserBackend,
- - which use the REMOTE_USER header for authentication purposes.</p>
- -
- - <p>In some circumstances, use of this middleware and backend could result in
- - one user receiving another user's session, if a change to the REMOTE_USER
- - header occurred without corresponding logout/login actions.</p>
- -
- - <p>To remedy this, the middleware will now ensure that a change to
- - REMOTE_USER without an explicit logout will force a logout and subsequent
- - login prior to accepting the new REMOTE_USER.</p></li>
+ <p>Django Ñ?одеÑ?жиÑ? Ð?Ð? пÑ?омежÑ?Ñ?оÑ?ного Ñ?Ñ?овнÑ?, django.contrib.auth.middleware.RemoteUserMiddleware,
+ а на движке аÑ?Ñ?енÑ?иÑ?икаÑ?ии — django.contrib.auth.backends.RemoteUserBackend,
+ коÑ?оÑ?ое иÑ?полÑ?зÑ?еÑ? заголовок REMOTE_USER длÑ? Ñ?елей аÑ?Ñ?енÑ?иÑ?икаÑ?ии.</p>
+
+ <p>Ð?Ñ?и некоÑ?оÑ?Ñ?Ñ? обÑ?Ñ?оÑ?Ñ?елÑ?Ñ?Ñ?ваÑ? иÑ?полÑ?зование Ñ?Ñ?ого Ð?Ð? пÑ?омежÑ?Ñ?оÑ?ного Ñ?Ñ?овнÑ? и Ñ?Ñ?ого движка можеÑ? пÑ?иводиÑ?Ñ? к
+ Ñ?омÑ?, Ñ?Ñ?о один полÑ?зоваÑ?елÑ? полÑ?Ñ?аеÑ? Ñ?еÑ?Ñ?иÑ? дÑ?Ñ?гого полÑ?зоваÑ?елÑ? в Ñ?лÑ?Ñ?ае изменениÑ? заголовка REMOTE_USER
+ без Ñ?ооÑ?веÑ?Ñ?Ñ?вÑ?Ñ?Ñ?иÑ? дейÑ?Ñ?вий по вÑ?одÑ?/вÑ?одÑ?.</p>
+
+ <p>Ð?лÑ? иÑ?пÑ?авлениÑ? Ñ?Ñ?ой пÑ?облемÑ? Ð?Ð? пÑ?омежÑ?Ñ?оÑ?ного Ñ?Ñ?овнÑ? вÑ?полнÑ?еÑ? пÑ?овеÑ?кÑ? Ñ?ого, Ñ?Ñ?о изменение
+ REMOTE_USER без Ñ?вного вÑ?полнениÑ? вÑ?Ñ?ода обÑ?заÑ?елÑ?но пÑ?иводиÑ? к вÑ?Ñ?одÑ? и поÑ?ледÑ?Ñ?Ñ?ей
+ пÑ?оÑ?едÑ?Ñ?е вÑ?ода до моменÑ?а пÑ?инÑ?Ñ?иÑ? нового REMOTE_USER.</p></li>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2014-0483";>CVE-2014-0483</a>
- - <p>Django's administrative interface, django.contrib.admin, offers a feature
- - whereby related objects can be displayed for selection in a popup window.
- - The mechanism for this relies on placing values in the URL and querystring
- - which specify the related model to display and the field through which the
- - relationship is implemented. This mechanism does perform permission checks
- - at the level of the model class as a whole.</p>
- -
- - <p>This mechanism did not, however, verify that the specified field actually
- - represents a relationship between models. Thus a user with access to the
- - admin interface, and with sufficient knowledge of model structure and the
- - appropriate URLs, could construct popup views which would display the
- - values of non-relationship fields, including fields the application
- - developer had not intended to expose in such a fashion.</p>
- -
- - <p>To remedy this, the admin interface will now, in addition to its normal
- - permission checks, verify that the specified field does indeed represent a
- - relationship, to a model registered with the admin, and will raise an
- - exception if either condition is not true.</p></li>
+ <p>Ð?нÑ?еÑ?Ñ?ейÑ? админиÑ?Ñ?Ñ?аÑ?оÑ?а Django, django.contrib.admin, пÑ?едлагаеÑ? возможноÑ?Ñ?Ñ?,
+ поÑ?Ñ?едÑ?Ñ?вом коÑ?оÑ?ой Ñ?вÑ?заннÑ?е обÑ?екÑ?Ñ? могÑ?Ñ? оÑ?обÑ?ажаÑ?Ñ?Ñ?Ñ? во вÑ?плÑ?ваÑ?Ñ?ем окне длÑ? иÑ? вÑ?боÑ?а.
+ ÐÑ?оÑ? меÑ?анизм оÑ?новÑ?ваеÑ?Ñ?Ñ? на помеÑ?ении знаÑ?ений в URL и Ñ?Ñ?Ñ?окÑ? запÑ?оÑ?а,
+ коÑ?оÑ?Ñ?е опÑ?еделÑ?Ñ?Ñ? Ñ?вÑ?заннÑ?Ñ? моделÑ? длÑ? оÑ?обÑ?ажениÑ?, а Ñ?акже поле, Ñ?еÑ?ез коÑ?оÑ?ое
+ Ñ?еализÑ?еÑ?Ñ?Ñ? данное оÑ?ноÑ?ение. ÐÑ?оÑ? меÑ?анизм вÑ?полнÑ?еÑ? пÑ?овеÑ?ки пÑ?ав доÑ?Ñ?Ñ?па
+ на Ñ?Ñ?овне Ñ?елого клаÑ?Ñ? модели.</p>
+
+ <p>Тем не менее, Ñ?Ñ?оÑ? меÑ?анизм не вÑ?полнÑ?еÑ? пÑ?овеÑ?кÑ? Ñ?ого, Ñ?Ñ?о Ñ?казанное поле пÑ?едÑ?Ñ?авлÑ?еÑ?
+ оÑ?ноÑ?ение междÑ? моделÑ?ми. Таким обÑ?азом, полÑ?зоваÑ?елÑ?, имеÑ?Ñ?ий доÑ?Ñ?Ñ?п к
+ инÑ?еÑ?Ñ?ейÑ?Ñ? админиÑ?Ñ?Ñ?аÑ?оÑ?а, а Ñ?акже доÑ?Ñ?аÑ?оÑ?нÑ?е знаниÑ? Ñ?Ñ?Ñ?Ñ?кÑ?Ñ?Ñ?Ñ? модели и Ñ?ооÑ?веÑ?Ñ?Ñ?вÑ?Ñ?Ñ?иÑ?
+ URL, можеÑ? поÑ?Ñ?Ñ?оиÑ?Ñ? вÑ?плÑ?ваÑ?Ñ?ие видÑ?, коÑ?оÑ?Ñ?е бÑ?дÑ?Ñ? оÑ?обÑ?ажаÑ?Ñ?
+ знаÑ?ениÑ? неÑ?вÑ?заннÑ?Ñ? полей, вклÑ?Ñ?аÑ? полÑ?, коÑ?оÑ?Ñ?е не пÑ?едназнаÑ?аÑ?Ñ?Ñ?Ñ?
+ Ñ?азÑ?абоÑ?Ñ?иком пÑ?иложениÑ? длÑ? показа в Ñ?аком виде.</p>
+
+ <p>Ð?лÑ? иÑ?пÑ?авлениÑ? Ñ?Ñ?ой пÑ?облемÑ? в инÑ?еÑ?Ñ?ейÑ?е админиÑ?Ñ?Ñ?аÑ?оÑ?а в дополнение к обÑ?Ñ?нÑ?м
+ пÑ?овеÑ?ка пÑ?ав доÑ?Ñ?Ñ?па вÑ?полнÑ?Ñ?Ñ?Ñ?Ñ? пÑ?овеÑ?ки Ñ?ого, Ñ?Ñ?о конкÑ?еÑ?ное поле пÑ?едÑ?Ñ?авлÑ?еÑ?
+ оÑ?ноÑ?ение к модели, Ñ?вÑ?занной Ñ? админиÑ?Ñ?Ñ?аÑ?оÑ?ом, и вÑ?зÑ?ваеÑ?
+ иÑ?клÑ?Ñ?ение в Ñ?ом Ñ?лÑ?Ñ?ае, еÑ?ли одно из Ñ?Ñ?ловий не вÑ?полнÑ?еÑ?Ñ?Ñ?.</p></li>
</ul>
- -<p>For Debian 6 <q>Squeeze</q>, these issues have been fixed in python-django version 1.2.3-3+squeeze11</p>
+<p>Ð? Debian 6 <q>Squeeze</q> Ñ?Ñ?и пÑ?облемÑ? бÑ?ли иÑ?пÑ?авленÑ? в пакеÑ?е python-django веÑ?Ñ?ии 1.2.3-3+squeeze11</p>
</define-tag>
# do not modify the following line
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXclMbAAoJEF7nbuICFtKl758P/27N+eFswZQTjCihBjtiZ2sK
gdu0PuG5PKUu9fKFYpCFI11MH3KS5a0XPFL58zBq2QgRj4W451TBfY9APRyaHsx9
C26Ekl3MFVUfpIkjRk4BiHDr7fqMD8AH8WtnqlFHB7FZtmuTteoQuxH3pFxdOk40
3DNiq1udjoK0cELVEtzBC3qeBexFgqy0d7q0iY8nm52JgojceRxK+x/ewVHW/yWT
Q7k3n+KxwmbVjYoy3PokbkGGO0A6XlHXB9TkaekdtTPClmW4ILouuGY8TpsNLs8Z
CajHl/cktBEB4yFcp0EYtJKQeoo1SPLJ7NNEtgnJz2OHeY1tsQTp81f3G54HIq+d
L6Jd3HV5J0I9C0Iy/mCGOWoz/e2LcAVT8Uj7l2twIb+rlkt3rBJEAFkttVBkV1iB
xfEmwFG+B9U/Mgz8iiqhMjXh//boA2k5KxfkWGFu5yZO8/aeYVqEuAZdY7q8i4IQ
Z1Ewzq/wND9eFneYrzSQSdgXI8bPr2rrJdyJ74sBdZkKSU+MLELrSz6uS2vHVgGX
zIDC2VbFcS3gSEc9ofYV8dO6x/LdO7/0QlEStk3nJIP5ZY/kJZLzFtkK56M2N48T
7XPF47R7ZkXWOBZCD4L7DOXRL5VRY2zX3do+YxYT+o+WVzwimVO31Si6TysbdZPs
etqudZUel2l101T+tXnc
=h29q
-----END PGP SIGNATURE-----
Reply to: