absc
/
dudeswave2
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
dudeswave2/dudeswave/src/dudeswave_user_handler.erl

96 lines
2.6 KiB
Erlang
Raw Normal View History

Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
%
% Copyright (c) 2024 Andrea Biscuola <a@abiscuola.com>
%
% Permission to use, copy, modify, and distribute this software for any
% purpose with or without fee is hereby granted, provided that the above
% copyright notice and this permission notice appear in all copies.
%
% THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
% WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
% MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
% ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
% WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
% ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
% OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
%
After some internal (with myself) debate, we will go with JSON. It just makes much more sense, to build a decent and modern platform.
2024-08-04 07:54:46 -04:00
-module(dudeswave_user_handler).
Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
-moduledoc """
After some internal (with myself) debate, we will go with JSON. It just makes much more sense, to build a decent and modern platform.
2024-08-04 07:54:46 -04:00
JSON API to manage users.
Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
""".
-behaviour(cowboy_handler).
-export([init/2, terminate/3]).
%
% Callbacks exports
%
-export([allowed_methods/2, content_types_accepted/2,
known_methods/2, resource_exists/2, is_conflict/2,
Improve the registration bit. Now, we return a proper answer when creating a user through a POST request. Maybe in the future we will convert the APIs to use JSON, like all cool kids do. However, it doesn't look like it makes much sense in this case.
2024-08-02 19:13:47 -04:00
previously_existed/2, allow_missing_post/2, create_user/2]).
Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
-include_lib("storage/include/storage.hrl").
-define(RANDBYTES, 32).
%
% Protocol functions
%
init(Req, State) ->
{cowboy_rest, Req, State}.
allowed_methods(Req, State) ->
We only allow POST for the registration form.
2024-08-02 17:46:24 -04:00
{[<<"POST">>], Req, State}.
Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
content_types_accepted(Req, State) ->
No, JSON is not needed here. For this simple blogging platform, let's start simple, basic HTML forms are enough.
2024-08-02 17:40:55 -04:00
{[{<<"application/x-www-form-urlencoded">>, create_user}], Req, State}.
Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
known_methods(Req, State) ->
No, JSON is not needed here. For this simple blogging platform, let's start simple, basic HTML forms are enough.
2024-08-02 17:40:55 -04:00
{[<<"POST">>], Req, State}.
Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
resource_exists(Req, State) ->
{ok, Bucket} = maps:find(bucket, State),
Just use the classic POST form. JSON doesn't make any sense in this case.
2024-07-27 06:36:14 -04:00
case cowboy:read_urlencoded_body(Req) of
{ok, [{name, Name}, {username, User}, {password, Password}], NewReq} ->
Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
case storage:read(Bucket, User) of
{ok, [_R]} ->
{true, NewReq, user_exists};
{ok, []} ->
{false, NewReq, {Bucket, [{name, Name},
Just use the classic POST form. JSON doesn't make any sense in this case.
2024-07-27 06:36:14 -04:00
{username, User},{password, Password}]}}
Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
end
end.
is_conflict(Req, user_exists) -> {true, Req, []};
is_conflict(Req, State) -> {false, Req, State}.
Improve the registration bit. Now, we return a proper answer when creating a user through a POST request. Maybe in the future we will convert the APIs to use JSON, like all cool kids do. However, it doesn't look like it makes much sense in this case.
2024-08-02 19:13:47 -04:00
previously_existed(Req, State) ->
{false, Req, State}.
allow_missing_post(Req, State) ->
{true, Req, State}.
Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
create_user(Req, {Bucket, [{name, Name}, {username, User}, {password, Pass}]}) ->
Use crypto:rand_seed(). It's cryptographically strong and set a better state for the pseudo-random number generator.
2024-07-27 07:16:05 -04:00
crypto:rand_seed(),
Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
Salt = rand:bytes(32),
No need to use an additional variable just to compose the salted pass.
2024-07-27 06:38:30 -04:00
Hash = crypto:hash(sha256, <<Pass/binary, Salt/binary>>),
Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
Improve the registration bit. Now, we return a proper answer when creating a user through a POST request. Maybe in the future we will convert the APIs to use JSON, like all cool kids do. However, it doesn't look like it makes much sense in this case.
2024-08-02 19:13:47 -04:00
URI = uri_string:recompose(#{
scheme => cowboy_req:scheme(Req),
host => cowboy_req:host(Req),
path => lists:flatten(["/user/", User])
}),
Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
case storage:write(Bucket, User, Hash, [{salt, Salt}, {name, Name}]) of
ok ->
Improve the registration bit. Now, we return a proper answer when creating a user through a POST request. Maybe in the future we will convert the APIs to use JSON, like all cool kids do. However, it doesn't look like it makes much sense in this case.
2024-08-02 19:13:47 -04:00
{{true, list_to_binary(URI)}, Req, []};
Enter the user handler API. For now it handles PUTs, to create new users. It's still a partial implementation and there is no documentation yet. POST, PATCH and DELETE will arrive later to handle other users operations.
2024-07-26 19:57:34 -04:00
{error, Reason} ->
{false, Req, Reason}
end.
terminate(_Reason, _Req, _State) -> ok.