API는 호출자와 피호출자 간의 계약입니다. 가장 흔한 형태의 API 오용은 호출자가 이 계약에서 자신의 몫을 이행하지 못하기 때문에 발생합니다. 예를 들어, 프로그램이 chroot()를 호출한 후 chdir()을 호출하지 못하면 활성 루트 디렉터리를 안전하게 변경하는 방법을 지정하는 계약을 위반하는 것입니다. 라이브러리 오용의 또 다른 좋은 예는 피호출자가 호출자에게 신뢰할 만한 DNS 정보를 반환할 것으로 예상하는 것입니다. 이 경우, 호출자는 자신의 행동에 대해 특정한 가정을 함으로써(반환 값이 인증 목적으로 사용될 것으로 예상) 피호출자 API를 오용합니다. 다른 쪽에서 호출자-피호출자 계약을 위반할 수도 있습니다. 예를 들어, 코더가 하위 클래스 SecureRandom을 지정하고 임의 값이 아닌 값을 반환하는 경우 계약을 위반하는 것입니다.
public
및 final
을 선언합니다.
@Immutable
public final class ThreeStooges {
public final Set stooges = new HashSet();
...
}
ctx = new InitialContext();
datasource = (DataSource)ctx.lookup(DB_DATASRC_REF);
conn = datasource.getConnection();
conn = DriverManager.getConnection(CONNECT_STRING);
--auto-tls
플래그를 true
로 설정합니다. 결과적으로 etcd 인스턴스는 클라이언트와의 TLS 연결에 자체 서명된 인증서를 사용합니다.
...
spec:
containers:
- command:
...
- etcd
...
- --auto-tls=true
...
RegisterModel
또는 Details
클래스에서 모든 속성으로 HTTP 요청 매개 변수를 바인딩합니다.
public ActionResult Register(RegisterModel model)
{
if (ModelState.IsValid)
{
try
{
return RedirectToAction("Index", "Home");
}
catch (MembershipCreateUserException e)
{
ModelState.AddModelError("", "");
}
}
return View(model);
}
RegisterModel
클래스는 다음과 같이 정의됩니다.
public class RegisterModel
{
[BindRequired]
[Display(Name = "User name")]
public string UserName { get; set; }
[BindRequired]
[DataType(DataType.Password)]
[Display(Name = "Password")]
public string Password { get; set; }
[DataType(DataType.Password)]
[Display(Name = "Confirm password")]
public string ConfirmPassword { get; set; }
public Details Details { get; set; }
public RegisterModel()
{
Details = new Details();
}
}
Details
클래스는 다음과 같이 정의됩니다.예제 2: ASP.NET MVC 또는 Web API 응용 프로그램에서
public class Details
{
public bool IsAdmin { get; set; }
...
}
TryUpdateModel()
또는 UpdateModel()
을 사용하는 경우 모델 바인더는 기본적으로 모든 HTTP 요청 매개 변수를 자동 바인딩하려고 합니다.예제 3: ASP.NET Web API 응용 프로그램에서 모델 바인더는 구성된 JSON 또는 XML Serializer/Deserializer를 사용하여 기본적으로 모든 HTTP 요청 매개 변수를 자동 바인딩하려고 합니다. 기본적으로 바인더는 HTTP 요청 매개 변수 또는 본문에서 모든 가능한 속성을 바인딩하려고 합니다.
public ViewResult Register()
{
var model = new RegisterModel();
TryUpdateModel<RegisterModel>(model);
return View("detail", model);
}
예제 4: ASP.NET Web Form 응용 프로그램에서 IValueProvider 인터페이스와 함께
public class ProductsController : ApiController
{
public string SaveProduct([FromBody] Product p)
{
return p.Name;
}
...
}
TryUpdateModel()
또는 UpdateModel()
을 사용할 때 모델 바인더는 모든 HTTP 요청 매개 변수를 자동 바인딩하려고 합니다.
Employee emp = new Employee();
TryUpdateModel(emp, new System.Web.ModelBinding.FormValueProvider(ModelBindingExecutionContext));
if (ModelState.IsValid)
{
db.SaveChanges();
}
Employee
클래스는 다음과 같이 정의됩니다.
public class Employee
{
public Employee()
{
IsAdmin = false;
IsManager = false;
}
public string Name { get; set; }
public string Email { get; set; }
public bool IsManager { get; set; }
public bool IsAdmin { get; set; }
}
Booking
클래스의 모든 속성에 바인딩합니다.
<view-state id="enterBookingDetails" model="booking">
<on-render>
<render fragments="body" />
</on-render>
<transition on="proceed" to="reviewBooking">
</transition>
<transition on="cancel" to="cancel" bind="false" />
</view-state>
Booking
클래스는 다음으로 정의됩니다.
public class Booking implements Serializable {
private Long id;
private User user;
private Hotel hotel;
private Date checkinDate;
private Date checkoutDate;
private String creditCard;
private String creditCardName;
private int creditCardExpiryMonth;
private int creditCardExpiryYear;
private boolean smoking;
private int beds;
private Set<Amenity> amenities;
// Public Getters and Setters
...
}
Order
, Customer
및 Profile
은 Microsoft .NET Entity 지속형 클래스입니다.
public class Order {
public string ordered { get; set; }
public List<LineItem> LineItems { get; set; }
pubilc virtual Customer Customer { get; set; }
...
}
public class Customer {
public int CustomerId { get; set; }
...
public virtual Profile Profile { get; set; }
...
}
public class Profile {
public int profileId { get; set; }
public string username { get; set; }
public string password { get; set; }
...
}
OrderController
는 요청을 처리하는 ASP.NET MVC 컨트롤러 클래스입니다.
public class OrderController : Controller{
StoreEntities db = new StoreEntities();
...
public String updateOrder(Order order) {
...
db.Orders.Add(order);
db.SaveChanges();
}
}
Order
, Customer
및 Profile
은 Hibernate 지속형 클래스입니다.
public class Order {
String ordered;
List lineItems;
Customer cust;
...
}
public class Customer {
String customerId;
...
Profile p;
...
}
public class Profile {
String profileId;
String username;
String password;
...
}
OrderController
는 요청을 처리하는 Spring 컨트롤러 클래스입니다.
@Controller
public class OrderController {
...
@RequestMapping("/updateOrder")
public String updateOrder(Order order) {
...
session.save(order);
}
}
null
을 반환하는 함수의 반환 값을 확인하지 않으므로 null 포인터를 역참조할 수도 있습니다.Equals()
를 호출하기 전에 Item
속성이 반환한 문자열이 null
인지 검사하지 않기 때문에 null
dereference가 발생할 수 있습니다.
string itemName = request.Item(ITEM_NAME);
if (itemName.Equals(IMPORTANT_ITEM)) {
...
}
...
null
값을 역참조하다가 중지해도 상관 없습니다.”null
을 반환하는 함수의 반환 값을 확인하지 않으므로 null 포인터를 역참조할 수도 있습니다.malloc()
이 반환하는 포인터를 사용하기 전에 메모리 할당이 성공했는지 확인하지 않습니다.
buf = (char*) malloc(req_size);
strncpy(buf, xfer, req_size);
req_size
가 너무 크거나 동시에 처리해야 할 요청이 너무 많아서 malloc()
호출이 실패했습니까? 또는 시간이 흐르면서 누적된 memory leak 때문에 발생했습니까? 오류를 처리하지 않고는 알 방법이 없습니다.null
을 반환하는 함수의 반환 값을 확인하지 않으므로 null 포인터를 역참조할 수도 있습니다.compareTo()
를 호출하기 전에 getParameter()
가 반환한 문자열이 null
인지 검사하지 않기 때문에 null
dereference가 발생할 수 있습니다.예제 2: 다음 코드는
String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM)) {
...
}
...
null
로 설정되면 해당 속성이 항상 정의된다는 잘못된 가정을 하는 프로그래머가 역참조하는 시스템 속성을 보여줍니다.
System.clearProperty("os.name");
...
String os = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95") )
System.out.println("Not supported");
null
값을 역참조하다가 중지해도 상관 없습니다.”