Комментарии 86
По поводу кода — шаблонизатор неплохо бы прикрутить, а то каша из php и html-кода ну как-то несерьезно.
Yet Another Helpdesk
А почему вы начали писать именно свой, самописный, хелпдеск?
Можно было взять ту же JIRA и настройками сделать то же самое, что есть у вас (и еще 90% функционала осталось бы в резерве).
Что сподвигло именно на написание?
А почему вы начали писать именно свой, самописный, хелпдеск?
Можно было взять ту же JIRA и настройками сделать то же самое, что есть у вас (и еще 90% функционала осталось бы в резерве).
Что сподвигло именно на написание?
Уж очень много захотелось тонкостей и по натуре, слишком придирчиво относился к мелочам. Как показывает опыт — эти мелочи, которые не нравятся в работе готовых хелпдесков постепенно перерастают в мешок неприятностей, после которого уже вобще не хочется работать с системой ни пользователям, ни админам. А уж разбираться в чужом коде, не понимать как он работает, внедрять свои штуки — вобще желания не было.
> взять ту же JIRA и настройками сделать то же самое
бгоооо. ты вот сначала попробуй. а потом говори.
бгоооо. ты вот сначала попробуй. а потом говори.
Ога — взять платную jira, выучить java, написать плагины. Отличный workflow.
На github, открываю первый файл и первое что вижу — SQL инъекция (к примеру: github.com/rustem-art/hd.rustem/blob/master/index.php#L27 ).
Да есть такое, поэтому я сразу оговорился: для внутреннего использования. В плане безопасности, мы эту стадию пропустили. Поэтому буду рад, если кто-то заинтересованый в этом проекте внесёт свой вклад в это направление.
Мне казалось что в 2014 году увидеть собирание запроса руками, а не использование параметров вообще невозможно, ан нет. Но зачем? Что для MySQL + PHP нормальных провайдеров не изобрели еще что ли до сих пор?
Да есть, конечно. Например, в PDO.
Изобретено давным-давно. Также как различные фреймворки/шаблонизаторы/ORM.
Почему автор избрал такой путь – загадка.
Почему автор избрал такой путь – загадка.
Я не знаю как вы с этим спите. Я когда подобное сделаю, потом не могу спокойно жить. Меня постоянно грызет совесть. :)
факт, что продукт внутренний не исключает безопасность) Вы думаете, у вас мало людей, которые бы не отказались получить админ-доступ в систему тикета и невозбранно пограбить корованы?
Для тех кто любит собирать запросы руками (я сам люблю что уж там) я бы предложил использовать PostgreSQL с его $$-quoting. Можно писать запросы типа INSERT INTO names VALUES ($qt$Вася$qt$);
$qt$ тут канает за кавычки, вероятность встретить такое в реальном тексте стремится к нулю (тем более что можно делать хоть $VladimirIlitchLenin$), так что включения этого маркера во входных данных можно выпиливать без зазрения совести.
$qt$ тут канает за кавычки, вероятность встретить такое в реальном тексте стремится к нулю (тем более что можно делать хоть $VladimirIlitchLenin$), так что включения этого маркера во входных данных можно выпиливать без зазрения совести.
Зачем? Dollar-quoted в постгресе придуман совсем не для этого.
Хотите собирать ручками – PDO предоставляет все средства для этого и от СУБД не особо зависим.
Хотите собирать ручками – PDO предоставляет все средства для этого и от СУБД не особо зависим.
А для чего он, в таком случае, придуман?
Все написано в доке.
Юзабельно, если надо работать с текстом непосредственно в базе, для работы через приложение интереса не представляет.
Юзабельно, если надо работать с текстом непосредственно в базе, для работы через приложение интереса не представляет.
Судя по указанному вами месту в доке, $$-quoting просто особенно удобен при написании хранимых процедур, но ничто не мешает использовать его в приложении (если не требуется совместимость со стандартом SQL).
Впрочем я не навязываю, PDO тоже вариант, просто проинформировал автора что есть такая возможность.
Впрочем я не навязываю, PDO тоже вариант, просто проинформировал автора что есть такая возможность.
Судя по указанному вами месту в доке, $$-quoting просто особенно удобен при написании хранимых процедурЭто:
it can be difficult to understand when the desired string contains many single quotes or backslashes, since each of those must be doubled. To allow more readable queries in such situations, PostgreSQL provides another way, called «dollar quoting», to write string constants.вы похоже пропустили.
dollar quoting имеет смысл (помимо процедур) при запросах с голым текстом
INSERT INTO val VALUES ($$'много'разного'текста'$$);
-- вместо
INSERT INTO val VALUES ('''много''разного''текста''');
На программном уровне (при работе с переменными) есть более удобные/наглядные/переносимые средства, чем использование $$-quoting.
$$-quoting отличная штука, но в данном топике она упомянута совсем не к месту.
PS что–то мы в оффтоп скатились, если есть желание, то приглашаю в личку.
Думаю в личку это плохая идея, если кто то найдет этот диалог то ему наверное будет интересно стоит использовать Dollar-quoting или нет :)
В общем то, абстрагируясь от предполагавшихся авторами PosgtreSQL сценариев использования $$, я просто утверждаю что код типа
является защищенным от SQL-иньекций. Разве нет?
В общем то, абстрагируясь от предполагавшихся авторами PosgtreSQL сценариев использования $$, я просто утверждаю что код типа
// допустим $_POST['name'] имеет значение "Вася $mytag$); DELETE * FROM peoples; --"
function Q($val) {return ' $mytag$'.str_replace('$mytag$', '', $val).'$mytag$ ';}
pg_query('INSERT INTO peoples (name) VALUES ('.Q($_POST['name']).')');
является защищенным от SQL-иньекций. Разве нет?
Ну можно, например, вместо обращений к $_POST[] использовать filter_input(). Кстати, не слишком старые интерпретаторы будут это в ворнингах предлагать делать.
Вы не могли бы пояснить, что плохого в отмеченной строке?
А, всё ясно, спасибо!
Когда то, очень давно в своих велосипедах делал так:
Пишу по памяти. Тоже самое можно делать и с $_GET. Веселые были времена :)
<?php
foreach($_POST as $key=>$val){
if(is_array($val)){
foreach($val as $key2=>$val2){
$val[$key2] = mysql_real_escape_string($val2);
}
}
else{
$_POST[$key] = mysql_real_escape_string($val);
}
}
Пишу по памяти. Тоже самое можно делать и с $_GET. Веселые были времена :)
Ну это как раз не очень хорошо :) Экранировать надо непосредственно перед постановкой в запрос. А то мало ли что ещё захочется со строкой сделать.
Инъекцию уже подправили.
Но таки да: стиль не айс, учитывая, что есть mysqli/PDO/ORM с вкусняшками, а mysql объявлен деприкейтнутым.
Но таки да: стиль не айс, учитывая, что есть mysqli/PDO/ORM с вкусняшками, а mysql объявлен деприкейтнутым.
Можно добавить еще «Шаблоны заявки» т.к. часто есть группа однотипных заявок. И типовые решения с возможностью быстрой ссылки на Центр знаний.
p.s. Эхх. Где вы были пару лет назад :)
p.s. Эхх. Где вы были пару лет назад :)
Очень напоминает YouTrack.
внешне выглядит симпатично, но код…
Код откровенно говно :) Это говорю Вам я, кто написал эту штуку. В этом посте мне хотелось бы меньше акцентировать на этом внимание.
А на что хотелось бы акцентировать внимание? Стоило ли делать свой хелпдеск? Так тут Вам-то виднее, какие у Вас и Вашего руководства были на него планы.
Самое очевидное, это то, что при большом желании и стремлении можно реализовать большинство средней сложности задач, даже не имея достаточных знаний в MVC, ООП, даже JS/PHP. Другой вопрос — стоит ли овчинка выделки, это уже мы посмотрим. Но в целом, для себя я вынес ключевые моменты, которые мне надо учить и подтягивать.
И ещё раз спасибо за критику и комментарии.
И ещё раз спасибо за критику и комментарии.
Другой вопрос — как :) У меня скоро будет проект, где нужен самописный хелпдеск, вот может созреем с ребятами взять за основу Ваш гитхаб и решить проблемы с кодом. Напишу Вам в личку, перед стартом, за разрешением, если примем решение идти по такому пути. Внешка неплоха, качество сервер-сайда неприемлемо.
Скажите, а сколько в общем человекочасов было потрачено на разработку/тестирование/тестовую эксплуатацию?
Идея хорошая, натягивать имеющиеся трэкеры на свою задачу не всегда оправдано. А качество кода очень пострадало (это я мягко, из уважения к проделанному труду и смелости поделиться этим на GitHub).
В соседнем топике как рас история об отказе от OTRS в пользу Jira habrahabr.ru/post/220823/
Количество sql инъекций просто очень большое (например, первый открытый файл), прячьте демо сайт.
Если захотите интегрировать телефонию с ним, то есть отличный вариант
Да ладно, код бывает и похуже, я свой внутренний хелпдеск примерно так же писал. Хотя переменные в запросах экранировал, конечно :)
Но мне свое выкладывать стыдно :(
А вот есть у нас интранет-сайт, писаный какой-тоубогой гениальной веб-студией еще лет 7 назад, так я до сих пор пожинаю результаты их труда, когда обновляется пэхапе и в этом чуде что-то ломается. Когда заглядываю в код — у меня из глаз начинает немного сочиться кровь… Маркетинг давно обещает нам новый, сияющий аяксом и прочим вебдванолем, сайт, но воз и ныне там…
Так что респект автору, ГУЙ очень неплохой, а остальное подтянется.
Но мне свое выкладывать стыдно :(
А вот есть у нас интранет-сайт, писаный какой-то
Так что респект автору, ГУЙ очень неплохой, а остальное подтянется.
использование как минимум PDO частично решило бы проблему экранирования при работе с бд и немножко защищала бы от sql инъекций. а вообще дело очень полезное. хорошо, когда руководитель понимает зачем это надо и помогает внедрять такое. а то тут у нас какбэ наоборот… ((
То факт, что проект выложили на гитхаб — это молодцы. Подскажите под какой лицензией? Если вдруг кто-либо захочет переписать на другой фреймворк/язык программирования?
Все уведомления на украинском?
Не должны как бы. Максимально переводили, единственное — что может не совсем точно перевели :)
У вас на первой демке (создание заявки) на украинском «Вкажіть підрозділ».
Спасибо, уже пофиксил. github.com/rustem-art/hd.rustem/commit/8f2af9a9e1005e2361fcef2a06ef91e24e4fd522
А уведомления о выполнении/изменении статуса заявки нет? и где подключается смс уведомления?
Уведомления приходят по 2 событиям:
1. Создана новая заявка
2. Перенаправлена новая заявка
Для нас такой подход был более приемлем, чем спамить на почту.
SMS-уведомления выпилены в той версии, что на гитхабе.
Но сделать это не составит труда, дописав функцию напр send_sms в functions.php и включив её в actions.php блок ($type == «add»), детальнее — пишите в личку или на почту — помогу.
1. Создана новая заявка
2. Перенаправлена новая заявка
Для нас такой подход был более приемлем, чем спамить на почту.
SMS-уведомления выпилены в той версии, что на гитхабе.
Но сделать это не составит труда, дописав функцию напр send_sms в functions.php и включив её в actions.php блок ($type == «add»), детальнее — пишите в личку или на почту — помогу.
Симпатично. Но как система ведет или будет вести себя на больших объемах данных? Сколько человек разрабатывало и поддерживает данную систему? Что будет, когда эти люди уйдут?
Это все конечно хорошо, но в 2014 году уже можно было бы познакомиться с продуктами компании Atlassian и не заниматься велопроизводством.
А меня очень заинтересовал ваш сервисдеск, как раз на днях искал что-то подобное: простое, удобное, не перегруженное и в тоже время довольно функциональное. Очень понравился интерфейс, как просторный дизайн так и хорошее юзабилити.
Пошел тестить, больше вам спасибо :)
Пошел тестить, больше вам спасибо :)
Интерфейсы у вас сделаны талантливо. То, чего так нехватает опенсорсным хелпдескам.
С радостью попробю ваш проект, удачи. И не бросайте это дело :)
С радостью попробю ваш проект, удачи. И не бросайте это дело :)
В любом случае, автор молодец! Решил задачу собственными силами, при этом, как мне кажется, не имея достаточного опыта в разработке.
Я тоже так начинал писать свой helpdesk, правда изначально был взят MVC и yii framework за основу, а понимание многих вещей пришло в процессе.
Я тоже так начинал писать свой helpdesk, правда изначально был взят MVC и yii framework за основу, а понимание многих вещей пришло в процессе.
Интересная штука получилось, но очень нехватает добавления заявок через E-mail (pop/imap, файл).
Пишите на github.com/rustem-art/hd.rustem/issues/new — и Вас обязательно услышат, и сделают то что хотите.
Правильно понимаете. Клиенты как таковые могут даже не знать что у фирмы есть такая система, которая ведёт их учёт и число обращений и тп.
Мы создали белый список login/email. Суть его заключалась в следующем: человек при входе через web кликает на ссылку «первый вход», и вводит только свой ldap-логин. На его доменную почту приходит письмо с созданным паролем и ссылкой, на которую он переходит и получает полноценный доступ к системе.
А почему так сложно? решение с доменной авторизацией (без хранения паролей в системе) и секьюрити группами почему не подошло? На мой вкус и проще и удобней и с блокировками в системах возиться не надо.
Del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы написали helpdesk