MALICIOUS_CODE EI_EXPOSE_REP Средний
для этого вам сначала нужно добавить edittext, где вы будете печатать данные из списка,
, затем включить фильтрацию в списке,
editText = (EditText) findViewById(R.id.searchList);
adapter = new CustomListViewAdapter(this,
R.layout.list_row, rowItems);
listView.setAdapter(adapter);
listView.setTextFilterEnabled(true);
Затем вам нужно добавить TextChangeListener() для edittext,
editText.addTextChangedListener(new TextWatcher() {
public void onTextChanged(CharSequence arg0, int arg1, int arg2,
int arg3) {
}
public void beforeTextChanged(CharSequence arg0, int arg1,
int arg2, int arg3) {
}
public void afterTextChanged(Editable arg0) {
MyActivityName.this.adapter.getFilter().filter(arg0);
}
});
3 ответа
I think the key here is the if:
If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different.
So in other words, if you wanted an immutable object (i.e. you didn't have a setBirthdate() method), your code be incorrect, because someone could write:
Date date = user.getBirthDate();
date.setMonth(1); // mutated!
So you would probably want the following instead:
public Date getBirthDate()
{return new Date(birthDate.getTime());} // essentially a clone
Well, I'd say that all depends. There are other non security-related reasons to return immutable objects, since it may also lead to some hard-to-find bugs in your code if the object is misused.
Is the class going to be accessed by untrusted code and/or data? If so, you need to have a clear idea of where the responsibility lies in your application with regards to validating input.
Also, what is the nature of the application? If it's e.g. an externally accessible network service then the input should almost certainly be considered potentially malicious. However if it's an application run locally with no priviliges which gets input from a trusted source, then probably no need to worry.
Yeah, I wouldn't really call it a ‘security’ issue as such... I mean, what attacker exactly is going to be writing malicious code against your objects? The real problem would be that you're quite likely yourself to trip up by accidentally calling getBirthDate then modifying the result.
For this reason, it is common to have your getter clone mutable objects like Date for returning, when you're using them as value types.
(You could also argue that Java's Date shouldn't have been made mutable, but there's not much can be done about that now.)