Простая реализация Token для взаимодействия мобильного приложения с WebAPI

[@Mikluho]

Ох, зря Вы так… Ведь и правда закидают.
Ваша реализация крайне небезопасна. С точки зрения механизма, у вас не токен, а сессионная кука.
Но хуже всего сама аутентификация. Серьёзно, поиск по частичному совпадению логина и пароль с чистом виде?

[@IT-AleX]

уж буду переделывать, по требованию СБ для выкладывания наружу — SSL + Token привязанный к устройству, но просто велосипед изобретался из-за желания простоты реализации и по причине того что в соответствии с мыслями, примеров не нашёл в сети :)

[@McElroy]

использования каких-нибудь пакетов из NuGet, чего хотелось бы по максимуму избежать

а в чем проблема использования пакетов из NuGet?

[@IT-AleX]

не люблю лишнее :) взять тот же пакет WinSCP… запарило… по непонятным причинам (не трогая NuGet) делаю релиз приложения WinForm выкладываю на ресурс, а выскакивает ошибка несоответствия версий между EXE и DLL… потому и не люблю лишнее… только от безысходности :)

[@McElroy]

т.е. Вы считаете, что это достаточный аргумент для написания велосипеда, вместо использования библиотеки, которая обкатана во многих проектах? а как же быть с .net core, там где Framework по NuGet пакетам распилили? будете весь Framework переписывать чтобы избежать использования NuGet?

[@nomoreload]

Для авторизации есть OAuth 2.0.
Для аутентификации — OpenID Connect 1.0.
Зачем изобретать изобретённое?
В случае дотнета — есть IdentityServer, который реализует оба протокола.

[@Daar]

Такие штуки я писал лет 15 назад :)))

[@yarosroman]

Эх огорчу вас с вашим велосипедом, в ASP.Net (что в Core, что в классическом) уже есть возможность работы с JWT Bearer токенами. В вашем велосипеде придется в каждый акшн добавлять проверку токена, когда при использовании JWT, просто добавить атрибут [Authorize] к контроллеру и все. Плюс, к тому токену можно прицепить кучу инфы(данные пользователя, время действия токена и тд.). А ваше решение даже безопасным нельзя назвать.

[@mayorovp]

Зря вы используете нестандартный заголовок HTTP без префикса X-, это может однажды плохо кончиться. Надо или использовать заголовок X-Token вместо Token, или воспользоваться стандартным `Authorization: Bearer ...` либо полустандартным `Authorization: Token ...`.

Ну и аутентификацию надо делать фильтрами, а не писать один и тот же код в каждом методе.

[@radium]

Рекомендация использовать X-префиксы устарела в 2012 году с выходом RFC6648.

Creators of new parameters to be used in the context of application
protocols:

1. SHOULD assume that all parameters they create might become
standardized, public, commonly deployed, or usable across
multiple implementations.

2. SHOULD employ meaningful parameter names that they have reason to
believe are currently unused.

3. SHOULD NOT prefix their parameter names with «X-» or similar
constructs.

[@Dobby007]

Оказывается пока приложение активно в App.Current.Properties могут хранится любые объекты, в том числе и объекты с данными собственных классов, но при «убиении» процесса если там было что-то отличное от «простых» объектов — содержимое App.Current.Properties отчищается, но если там хранить только простые объекты — string, bool, int и т.п. то всё останется сохраненным!

Я не работал с Xamarin, но мне кажется, что тут дело в возможности сериализации объектов. Вы не пробовали пометить свои кастомные классы атрибутом Serializable?

[@IT-AleX]

пробовать не пробовал, но вопрос — почему они «живут» пока работает приложение, и уничтожаются при убиении процесса приложения?.. при тех же данных — если в проперти «простые» объекты — уничтожения нет…

[@McElroy]

вероятно, причина в том, что .net знает, как сохранять «простые» объекты, а как быть с Вашими — нет