Sinatra 프로젝트 그룹 Flatiron School(mod2 프로젝트)!

시나트라 최종 투자조합 프로젝트
mod2에서는 시간이 빨리 지나간다.처음에는 아르바이트를 하다가 전업이 되었다.이것은 내가 변화를 한 후 일주일 동안 프로젝트를 고려해야 한다는 것을 의미한다. 왜냐하면 프로젝트가 곧 시작되기 때문이다.
나는 햄 일지를 만드는 것을 선택했다. 왜냐하면 햄 라디오는 나의 취미 중의 하나이기 때문이다. 나는 이것이 우리가 배운 시나트라에 관한 지식을 응용할 수 있는 충분한 공간을 줄 것이라고 생각한다.
mod 1의 기초 지식을 배운 후 우리는 시나라에 잠입했다.Sinatra는mod1에서 배운 많은 프로그래밍 지식을 가져갔지만, 추가 방법을 통해 흥미로운 특성을 가져왔다.Active Record,Sinatra의 루트, 모듈, 보기, 컨트롤러의 MVC 구조,Sinatra와Active Record, 사용자 인증을 이해했습니다.이렇게 짧은 시간 안에 거의 너무 많았지만, 우리는 그것을 성공적으로 장악했고, 우리는 지금 우리의 투자조합 프로젝트에서 그것을 보여줄 수 있다.
소개된 흥미로운 gm은 bcrypt입니다.ActiveRecord 宏has secure password와 결합하여 사용합니다.매크로에는 Bcrypt 암호를 기반으로 설정하고 검증할 수 있는 secure password writes 방법이 있습니다.이 메커니즘은 필요한 암호의 속성 이름으로 (attribute) 요약을 요구합니다.또한 사용자 객체를 만들 때 암호를 입력해야 한다는 요구 사항도 추가되었습니다.또한 암호 길이가 72바이트 이상인지 확인하고 암호 확인에 선택할 수 있는 암호 확인 속성을 제공합니다.
Bcrypt 자체는 암호의 디지털 지문을 얻는 해시 메커니즘이다.해시에서 비밀번호를 복구할 수 없습니다.그러나 해커는 bcrypt 알고리즘을 사용하여 산열 암호 데이터베이스를 만들 수 있다.만약 데이터베이스가 파괴된다면 해커는 해시에게 비밀번호를 찾기 위해 역방향 검색을 할 수 있다.해커가 해독하기 어려우면 암호를 해시 연산하기 전에 랜덤 블록(salt)을 암호에 추가할 수 있다.이것은 해커가 필요로 하는 데이터베이스로 하여금 저장 공간에서 가능한salt와 암호 산열을 생성하게 할 것이다. 이것은 불가능할 가능성이 높다.그러면 간단한 사전 공격에서 가능한 소금을 포함해서 그들이 남은 것은 무엇입니까?이것이 바로 bcrypt의 장점이다. 왜냐하면md5 등 다른 알고리즘에 비해 이 알고리즘은 상대적으로 느리기 때문이다.암호를 해산하는 데 더 많은 시간이 걸리기 때문에 해커가 암호를 추측하는 속도를 늦출 수 있다.
Bcrypt는 백엔드에서 저희를 위해 일하고password=방법을 제공합니다. 이 방법은 주어진 명문 암호를 바탕으로 암호화 암호를 생성하여 암호 요약에 저장합니다.
암호를 입력하지 않고 새 사용자 인스턴스를 만들려면 다음과 같이 하십시오.

 pry(main)> user = User.new(username: "john", password: "")
=> #<User:0x00007f80525718c0
 id: nil,
 username: "john",
 password_digest: nil,
 name: nil,
 email: nil>
 pry(main)> user.save
=> false

명령줄에서 사용자 대상의 새로운 실례를 만들 수 있지만 저장할 수 없습니다.사용자로서create가 소유하고 있습니다.저장 방법이 내장되어 있습니다. 이것도 실패할 것입니다.

pry(main)> user=User.create(username: "john", password: "")
=> #<User:0x00007f80525db248
 id: nil,
 username: "john",
 password_digest: nil,
 name: nil,
 email: nil>
 pry(main)> User.last
=> #<User:0x00007f8052618f80
 id: 4,
 username: "af5se",
 password_digest:
  "$2a$12$Qbg0kWJQSzdBcdM1wCc4Tefe4U4wAFEL/ADRdFOL1MUleIYXt/Mna",
 name: "John",
 email: "">
 pry(main)> 

이전 절에서 보듯이 새로 만든 사용자 대상은 데이터베이스에 오래가지 않습니다.다시 말하면에 포함된 메서드를 저장합니다.암호가 존재하지 않기 때문에 create 방법이 실패했습니다. 암호를 제공하면,create 방법은 nil이 아닌 id 값으로 만든 대상을 표시합니다.이로써 우리는 이 대상이 이미 성공적으로 데이터베이스에 영구화되었다는 것을 알 수 있다.

pry(main)> user=User.create(username: "alex", password: "1234")
=> #<User:0x00007f8052318f88
 id: 8,
 username: "alex",
 password_digest:
  "$2a$12$5GqNWDrtxQMnsmnmixU0N.WiflNh0BX/DMarA3JUlz0ya9bF5GUuS",
 name: nil,
 email: nil>
[13] pry(main)>

암호를 추가하면 사용자 객체가 성공적으로 저장되어 데이터베이스에 저장됩니다.

pry(main)> user.password = '1234'
=> "1234"
 pry(main)> user.save
=> true
 pry(main)> User.last
=> #<User:0x00007f80554f54c0
 id: 7,
 username: "john",
 password_digest:
  "$2a$12$O4u602uMzjxy529e9VNX4.Oe73GbzNvjGRXVsXLagw6NySPldHVXa",
 name: nil,
 email: nil>
 pry(main)>

우리가 정확한 비밀번호를 사용하여 사용자와 신분 검증을 시도할 때 사용자 대상은 되돌아옵니다.

pry(main)> user.authenticate('1234')
=> #<User:0x00007f80525db248
 id: 7,
 username: "john",
 password_digest:
  "$2a$12$O4u602uMzjxy529e9VNX4.Oe73GbzNvjGRXVsXLagw6NySPldHVXa",
 name: nil,
 email: nil>
 pry(main)>
With an wrong password we will see this.

pry(main)> user.authenticate('wrong password')
=> false
 pry(main)>

나의 프로젝트에 관해서 위에서 말한 바와 같이 나는 일지를 만들기로 결정했다.햄 라디오로 만든 통신록을 저장할 수 있는 곳나는 데이터베이스에 세 개의 표를 만들었는데 그것이 바로 사용자, 호출 번호와 연락처이다.한 사용자가 많은 호출을 할 수도 있고, 호출을 통해 많은 연락처를 할 수도 있다.호출 번호는 사용자에 속하며, 호출 번호는 많은 연락처가 있을 수 있다.마지막으로 연락처는 호출 번호에 속한다.
보통 한 사용자가 호출 번호 하나만 있으면 충분하다.호출 번호는 일반적으로 FCC에서 생성되며, 사용자의 라이센스가 유효한 경우(2년 유예 기간까지), 호출 번호는 사용자의 범주(기술자, 일반 또는 추가)와 관계없이 계속 존재합니다.이때 보낸 새 호출 번호는 두 글자, 한 지역 번호와 세 글자로 구성된다(2017년 12월 내 호출 번호는 KG5WJQ이다).그러나 허영호를 신청하는 것은 가능하다.허가증 종류에 따라, 이것은 호출 번호가 훨씬 짧다는 것을 의미할 수 있다.이것은 내가 2018년에 하고 얻은 K5GT이며,HamLogbook의 홈페이지에도 나타난다.따라서, 내 경우, 비록 나의 옛 호출 번호는 더 이상 유효하지 않지만, 나는 여전히 연락처가 있다. 이 연락처는 이 호출 번호나 둘의 조합 기록을 사용하는 인증서에 유효하다.
이것은 내 로그에서 사용자가 여러 개의 호출을 할 수 있다는 결정을 내렸다.사용자의 테스트 결과 때문에 도전도 가져왔다.연락처는 어떤 호출 번호를 사용했는지 고려하지 않고 사용자가 하는 모든 연락처를 포함할 것이다.따라서 연락처를 확인하고 싶은 호출 번호를 선택하는 방법을 찾아야 한다.나는 세션에서 선택한 호출 번호를 저장해서 이 문제를 해결한다. 그러면 세션 [:callsign]을 통해 이 문제를 얻을 수 있다.이 sesion[:callsign]은 Callsign Controller에서 설정하고 사용자가 홈 페이지를 로그아웃하거나 방문할 때nill로 설정합니다.
내 세 개의 시계, 사용자, 호출 번호와 연락처로 인해 나는 세 개의 동명 모델이 있다. MVC(모델 보기 컨트롤러) 구조를 완성하기 위해 나는 모든 모델에 속하는 보기와 컨트롤러를 만들었다.모델은 대상을 정의하는 곳입니다. 보기는 대상을 표시하는 페이지가erb 파일과 컨트롤러에 나타나는 곳입니다. 컨트롤러에서 보기와 필요한 데이터를 전달하기 위해 조작을 수행합니다.나는 사용자와 세션을 만들고 로그인하는 것을 책임지는 추가적인 Session Controller를 만들었다.
우리는 CRUD, CRUD, Create, Read, Update, Delete를 사용하여 우리의 데이터를 처리합니다. 우리의 html 폼 방법은 또 다른 도전에 직면합니다.html 폼에 GET와 POST가 있기 때문에 창설하고 읽는 것은 문제가 되지 않습니다.그러나 CRUD의 UD 부분에 대해 우리는 html표에서 실현되지 않은 두 가지 방법이 필요하다.Lucky for use Rack에서는 구성에서 이 모듈을 호출할 수 있는 Method Override 모듈을 출시합니다.ru 파일, 비헤이비어 Rack::MethodOverride.이 모듈은 html 폼에 추가 입력 줄을 추가할 수 있습니다.name="method"을 사용하고value 필드value="patch"또는value="delete"에 필요한post 방법을 놓을 수 있습니다.
예를 들면 다음과 같습니다.

<form method="post" action="/contacts/<%[email protected]%>">
            <input id="hidden" type="hidden" name="_method" value="patch">

나는 확실히 프로필의 위치를 발견했다.ru 파일이 정말 중요합니다.반드시 그것을 너의 컨트롤러 위에 놓아야 한다. 나는 어려운 방식을 통해 발견했다. 이것은 확실히 나에게 약간의 시간이 걸렸다.패치와 삭제를 제외한 내 컨트롤러의 모든 경로가 정상적으로 작동하고 있다.나는 단지 나의 종적 속에서만 댓글을 보았을 뿐, 지금까지 패치를 본 적이 없다.
이 모든 것은 매우 재미있어서 나는 많은 것을 배웠다.이 프로젝트는 예상보다 일찍 왔지만, 그것은 나를 완전히 다른 길로 가게 했다. 왜냐하면 나는 지금 전업이기 때문이다.다음 프로젝트는 내가 더 잘 준비할 수 있을 것 같아서 나는 매우 기대한다.