« Отговор #23 -: Feb 14, 2010, 12:57 »
Здравейте всички,
Ще се опитам да напиша по няколко реда в отговор. Надявам се да разберете правилно защо нещета са в това състояние. Аз самият използваm linux базирани ОС за десктоп от няколко години, а по сървъри от края на 90те. Затова и определено ми се иска нещата да не са в сегашното състояние.
@Kras
Това спокойно може да се постигне с GreaseMonkey скрипт, който шунтира COM обекта за подписване, дава ти възможност да си запишеш като файл това, което трябва да се подпише, подписваш си го с каквото решиш (openssl) и след това го upload-ваш. Това ще работи като цяло за всички услуги, без ДДС-то, където живее "омразната" ви ActiveX контрола. Отново ще наблегна - ако се отворят интерфейсите от НАП, ще може да се реализира всичко. Ето ви подобен паралел - никой не натиска микрософт да си подкара офис пакета под линукс, защото са в монополно положение на пазара на офис пакетите. Натискат ги да отворят файловите си формати.
@laskov, plandz
идеите все някъде трябва да се раждат и обмислят. Иначе постоянно ще се изправяме пред поредните криви имплементации на услуги, които никой не използва. Аз лично съм отворен и положително настроен към всяка помощ. Но разберете, не става да отида в организацията Х и да им предложа "хайде да платите за платформена независимост на клиентите, ще бъде от полза на 0.3% от потребителите ви". Или пък обратното - да планирам при нас ресурс, който след това не мога да защитя финасово.
@v_badev
Има една приказка, че човек като не знае какво да прави, прави каквото знае. Въпросната контрола е подписана по AuthentiCode, маркирана е safe for scripting, не й трябват административни права за изпълнение. Ако някой си направи труда да зачете докуемнтацията, ще намери точно какви специфични настройки трябва да се направят, за да работи както трябва, без да се застрашава сигурността на потребителя. Само, че клиентите бързат и е най-лесно "всичко надолу".
Това, което са направили колегите от Банксервиз не съм го виждал, но предполагам, че не просто сваля всичко на макс - останал съм с впечатлението, че могат и повече.
На това за валидацията искам да обърна специално внимание. Не става въпрос за верификация на подписа при клиента. Това се прави на сървъра. При клиента се прави формален контрол на файловете, които се изпращат - за да можем да му съставим декларация и да имаме една идея по-голяма увереност, че е избрал правилните файлове, не ги разкарваме през Интернет излишно и пр. ВСИЧКИ формални валидации се повтарят и на сървъра, в комплект с още някои други, за които е необходима още информация.
Въпросния java applet, който реферираш в агенцията по вписванията, беше писан(или поне в началото) от Петър Пенчев (roamer), ако чете тук може да сподели какво е наложило това решение. Уверен съм, че има доста добра причина.
Ако имаш опит с кодовото дърво на wine и ти се занимава, може да объдим къде точно е проблема, а и да поработим за решаването му. Не мисля, че в този тред е подходящо да изпадаме в технически подробности.
@dvasilev
Вярвам, забелязал си, че оправдания не търся. Излагам как стоят нещата и посочвам възможните решения. Това с PDF-ите не е писано от нас и съвсем скоро ще бъде заменено с аналогично решение, в унисон с технологичната рамка на НАП. Декларации 1,3 и 6, както и трудовите договори (по чл 62 и 123 от КТ) е услуга, пусната преди 2-3 години. Там реализацията е с COM, който подписва локален файл, който след това се upload-ва. Подходът, за който писах по-горе с GraceMonkey скрипт е приложим директно.
Накрая, ако някой има желание да помогне, вместо да критикува непознавайки пълната картинка, нека пише.
Автор
Тема: Мога ли да осъдя НАП (Прочетена 36916 пъти)